October 2022 is bringing with it enhanced degrees of difficulty and uncertainty, the financial climate in general, and especially the high-tech industry is turbulent and unclear.

The beginning of Q4 is usually crunch time for most companies. It was during my tenure at IBM that I took the crash course on this subject. There is no better school for “End of year” strain than the one at a publicly traded company and if it’s an international corporate traded on NASDAQ even better. There is no tomorrow after December 31^st.

All the Milestones, releases, demos, POCs that you committed to delivering throughout the year and postponed/forwarded to the next month must be delivered. All 2022 related investments, bonuses, and terminations… are knocking on your door and as always, time and resources’ availability are not your allies.

2022’s end is not business as usual, as in the 1939 “The Wizard of Oz”, Dorothy says to her dog at one point: “Toto, I’ve got a feeling we’re not in Kansas anymore.” Recent management research and publications are addressing the fact that traditional/textbooks/best practices of business strategy (and tactics) are becoming futile once facing the fast pace of change and continuous uncertainty that we’re facing.

October 2022 is bringing with it an enhanced degree of difficulty and uncertainty, the financial climate in general, and especially the high-tech industry is turbulent and unclear. This environment is adding two crucial parameters to the equation. Imminent demand to economize which is corporate slang to cut costs dramatically. The demand to stretch the “runway” is amplified by the second variable which is the lack of visibility to 2023 budgets, information that will enable us to take the necessary actions and investments that will not become obsolete on January the 1^st. The new (business) world order requires us to be more agile, resilient, and decisive.

Paving course of action will start with mapping out our situation, starting with our 2022 “commitments” and available resources and transforming them into 2-3 alternative high-level release plans. We should incorporate issues like the order of importance and levels of risk. Once articulated, we will perform a crucial step which is foretelling the worst-case scenario for each alternative. This action will inhibit the Project Planning Fallacy (a common bias that implies, however long you think you need to do a task, you will actually need longer. Regardless of how many times you have done the task before, or how deep your expert knowledge is). In regular times this phenomenon has damaging potential. During Q4, it becomes extremely critical, there will be no overtime after December 31st. The conclusion of the process will include the selection of the optimal release plan and the construction of a detailed release plan (Sprints level).

At this point in time, missions are prioritized and the list of the required resources is established. The first choice is usually diverting resources from less crucial activities, if applicable, great. Nonetheless, we’re required to double-check that we’re not inflicting over “less short-term” (Q1 release dates are right around the corner) for the short-term demand. If this solution isn’t feasible the next step is checking our recruitment pipeline to review whether there are candidates in advanced stages and can be signed in the next week or so. The “usual” challenge with this path is that even if there are potential recruits their notice time plus onboarding duration (30 – 45 days) will prohibit any real Q4 contribution. This year “unusually” there is a chance that there is no open position for recruitment chances are slimmer than regular.

Once internal alternatives are exhausted, we should consider an external team enhancement. To those of you that are puzzled by the inconsistency between “external” and “reduced cost,” the answer is: consider a team that is onboarded ASAP and dismissed at the end of the year. No residual effect on other R&D commitments or recruitment/notice costs. If you want to go the extra mile, you may even consider going offshore. The issue with offshore development at the end of the year is that usually they are one week short at the end of December, one very crucial week. On the other hand, there are hybrid Israeli-offshore solutions that will enable us to attain reduced costs and the additional working week of the 25^th.

The team is established, the backlog is set, and the first sprint commenced. There is an additional factor that can increase the probability of success. We should establish process transparency with our team. Maximizing knowledge of the situations and the context will enable the team members to both adapt and step up for the occasion.

At times like these, I recommend embracing the legendary basketball coach and leadership guru, John Wooden’s words of wisdom “Do not let what you cannot do interfere with what you can do”.

It’s time for operational efficiency?, click for more information on how CodeValue cab assist you with OPERATIONAL EFFICIENCY

Published by Hanan Zakai

VP Customers & Division Manager @CodeValue

It has been 2 years since we’ve had the pleasure to meet and greet in person, and the long wait was worth it! over 420 people gathered for a full day of invigorating talks, mingling, and some good food.

What was it all about?

Time brings change, and COVID has played its role as a catalyst in that matter. Recent effects have led to an unprecedented shift to remote-first work culture and accelerated multi-cloud adoption, not only in terms of harnessing tools and platforms to be used to serve one’s business but also in the products and systems that the company builds, demanding elevated requirements regarding hybrid and cross-platform scenarios. 

In the software industry, we are expected to be agile and adapt to changes quickly and effectively. This isn’t related merely to development but spans the entire business, product, R&D, UX/UI, architecture, technology, development, and DevOps. 

The need for building software that can operate on and/or integrate with different platforms is rising steadily. New levels of productization, process, and automation are required to meet the new challenges at a high pace, as well as find effective ways to scale MVP products and R&D. 

Therefore, our job as leaders, architects, and engineers, to figure out how to build and best use technologies, tools, and platforms to meet such diverse needs and scenarios, has become more and more challenging. 

This was the fifth consecutive year of CodeValue’s Architecture Next conference. Throughout the day we discuss revolutionary and innovative concepts, technologies, and tools while showing how these can be leveraged and applied to make business, processes, and systems better. 

• 

• 

• 

• 

General assembly

The conference day was launched with an introduction by SpeedValue’s & CodeValue’s CEO Tali Shem Tov and Chairman Ayal Zylberman. Tali & Ayal delivered a brief talk about the changes we have all experienced during the last 2 years and what those changes entailed for our industry.

Keynote: Architecture Stories from the Trenches – Alon Fliess

The keynote session was delivered by Alon Fliess, CodeValue’s Chief Architect that shared with the audience his experiences of over 30 years of significant software development, design, and architecture projects for global leading and cutting-edge companies. 

Software Architecture in the Multi-Cloud Era – Amir Zuker, Rotem Barda (Vayyar), Barak Mor

This talk is about building systems with respect to multi-cloud, focusing on architecture and technological concepts in addition to business aspects. One of the key principles to achieve it is to build the right abstractions.

How do you do that though? There are so many options to choose from, what are they and how do you implement them? In this session, we tackled these subjects head-on while sharing real interesting demos in the process. Furthermore, we presented a real-world case study of one of our existing customers, Vayyar, and discussed our journey together in transforming their business, product, and technology towards multi-cloud.

Experts Panel

Alon Fliess, Amir Zuker, Hanan Zakai, Amit Kinor, Tomer Karasik, Nir Dobovizki, Eran Barghil.

---

Executive Track

The Perfect Host – An Ongoing Story

Alon Fliess, Chief Architect at CodeValue (MVP & Microsoft Regional Director).

Web3: From A to S (Security)

Tal Be’ery, CTO Zengo

From Offshore to Global Delivery

Tali Shem Tov, CEO & Co-owner, CodeValue & Esti Felba Hermesh, Director of Global Delivery, CodeValue.

Artificial Intelligence, Machine Learning (and when not to use them)

Nir Dobovizki, Senior Consultant and Software Architect & Backend Practice Lead  @CodeValue

---

Technologies Track

Composable Components – Play Application Lego

Tomer Karasik, Technical Lead and Software Architect at CodeValue & Ilya Holtz, Senior Full Stack Developer at CodeValue

Building Modern IoT Data Pipelines

Alon Amsalem, Software Architect & CodeValue

Micro Front End – Web-Components in Practice

Yehuda Buzaglo, Senior frontend @CodeValue

Digital Transformation is one of the most profound changes happening in the technological world around us. More businesses understand that they must level up their tech strategy or be left behind. With a massive amount of cloud, AI/ML, and other emerging technologies, software professionals and decision-makers have difficulty keeping up to date.

How can we achieve Digital Transformation? How can we translate those high-level principles and fancy words to ideas and plans to implement in our software? This is what this year’s Architecture Next was for.

At Architecture Next 2021, we discussed revolutionary concepts and tools for the fourth consecutive year and showed you how they can be applied towards making your next software system a better one. We saw how you could implement Digital Transformation in your software systems and how you could utilize your software architecture to accomplish more.

General assembly

The conference day was launched with an introduction by CodeValue’s CEO, Tali Shem Tov. Tali delivered a brief talk about what is Digital Transformation and where does it meet CodeValue’s offering.

Keynote: the IDF’s Journey to the cloud

The keynote session was delivered by the guest speaker “Merav” An officer in the IDF’s Digital Transformation Directorate who took us along the IDF’s journey to the cloud.

The IDF's journey to the cloud – Merav from CodeValue

---

Executive Track

Digital Transformation – Buzzword or Reality

The first session on this track was given by Alon Fliess, Chief Architect at CodeValue (MVP & Microsoft Regional Director). In his session, Alon states that there are only two types of organizations, those that already realized that they are software shops and those that haven’t. This introductory session discusses the digital transformation revolution, what it is? and what any organization should do about it? Alon discusses the analysis process, the effect on the products or services, the human resource, and the technology perspectives.

Digital transformation buzzword or reality – Alon Fliess from CodeValue

---

Designing Products in the Digital Transformation Era

The second session was given by Eyal Livne Senior User Experience Architect at CodeValue. In his talk, Eyal introduces the CodeValue workshop as the flagship ‘getting started’ method for initiating a successful digital transformation. 

Designing products in the digital transformation era – Eyal Livne from CodeValue

---

Application Evolution Strategy

Eran Stiller, CodeValue’s CTO gave the third session on this track, in which he reviewed the technical methods we have to modernize our software systems. He reviewed the questions that we should ask ourselves and the strategies that we can employ. Starting from lift & shift through containerization to cloud-native apps – He’s taking you on a journey that’s relevant for any modern software’s stakeholder.

Application evolution strategy – Eran Stiller from CodeValue

---

The IoT Transformation and What it Means to You

The 4th session on this track we had the pleasure to hear Nir Dobovizky, a Senior Consultant and Software Architect at CodeValue. In his talk, Nir covered why IoT is as important as the hype says and what it means for your business

The IoT Transformation and What it Means to You – Nir Dobovizky from CodeValue

---

What Can You Do When Your Release Plan is Being Concluded at the HR Office?

To conclude the Executive track we heard Hanan Zakai CodeValue’s Technology Division Manager shading light on the lessons learned from Andi grove (the legendary Intel’s former CEO), the competition between Netflix & Blockbuster, and the Challenger’s crash disaster to articulate the real recruitment challenge and its magnitude and establish the means to face them and even create new opportunities.

When your release plan is concluded at the HR office – Hanan Zakai from CodeValue

​

Modern Technologies For Digital Transformation Track

State in Stateless Serverless Functions

To kick off the “hands-on” track, Alex a Software Architect at CodeValue, talked about how we can manage state in a stateless, serverless environment on Azure, by utilizing Azure Durable Functions and how we can use the eco-system to build entire systems, completely serverless. 

State in stateless serverless functions – Alex Pshul from CodeValue

---

How I Built a ML-human Hybrid Workflow Using Computer Vision

The second session in this track was given by CodeValue’s Amir Shitrit a Software Architect at CodeValue. In this talk, Amir demonstrated how he built business workflows using the joint effort of humans and software to automate those boring tasks, while compensating for the inaccuracy of ML with human intervention.

How I built a ml human hybrid workflow using computer vision – Amir Shitrit from CodeValue

---

We Come in Peace: Hybrid Development with WebAssembly

Following Amir, Maayan Hanin a prominent Software Architect at CodeValue examined the relationship between WebAssembly, JavaScript, TypeScript, the browser, and other hosting environments.

​

We come in peace hybrid development with web assembly – Maayan Hanin from CodeValue

---

Will the Real Public API Please Stand Up?

Amir Zuker is a Senior Software Architect and our Web & Mobile Division Leade. Amir concluded this track with a discussion about authoring Public API’s between systems, be that different parts within the same distributed system or a fully blown real-world public API and everything in between.

Will the Real Public API Please Stand Up? Amir Zuker from CodeValue

---

Panel -Architecture for Digital Transformation

The topping on the ice cream was the Digital Transformation experts panel, hositng our own experts: Alon, Eran, Amir, Maayan, Nir, Eyal & Hanan . In the panel, the experts talked about all things Digital Trnasformation and answered questions

We are here for you

Need Consulting or development services? Contact us via the form below. in the meantime, thank you and see you next year!

חברות רבות עוברות לענן הציבורי, חלק ניכר מהן עושות זאת לבד, עם ידע בסיסי בלבד בענן על תכונותיו ויכולותיו. מנהל מערכות המידע או הדבאופס של הארגון נכנס לפורטל של חברת הענן, מזין פרטים ואמצעי תשלום ומתחיל להקים סביבה ולבנות את מערך תשתית הענן על פי הידע הקיים אצלו, אשר לעיתים לוקה בחסר

המוטיבציה מונעת כמעט תמיד מתוך הרצון הלגיטימי לחסוך כספים לארגון ומתוך כך הבחירה לוותר על מעורבות של שותף ולעבוד ישירות מול חברת הענן. ברוב המקרים, צורת עבודה זו אינה תואמת את שיטות העבודה המומלצות המוגדרות ע”י חברת הענן, מה שהופך את העבודה לפחות יעילה, פחות בטוחה ויותר יקרה

עבודה עם שותף (ספק שירותי ענן מומחה), בעל ניסיון והבנה בעולמות הענן תייצר ערך אדיר ללקוחות אלו. שותפים רבים מציעים שירותי ענן, חלקם עובדים עם ענן אחד ספיציפי ובונים התמחויות בו, אחרים עובדים עם יותר מחברת ענן אחת ומציעים גמישות בבחירת סביבת הענן

שותפים מסוימים מגיעים מעולמות מערכות המידע עם התמחות בתשתיות מקומיות ואדפטציה לתשתיות בענן, אחרים מגיעים מעולמות הרישוי ומספקים שירותי ענן לאחר שגייסו את המומחים הרלוונטיים. ספקי שירותי ענן מסוימים מציעים את מכירת שירות חברת הענן בלבד, אחרים מספקים גם שירותי מומחה לסיוע ללקוח בבניית התשתיות. מעבר לכך, ישנן חברות כמו קודווליו אשר מתמחות באפליקציות ובטרנספורמציה דיגיטלית ומספקות שירותי ענן גם ברמת הקוד ולא רק ברמת התשתיות בענן ובכך מסייעות ללקוחות לבצע מודרניזציה גם לתשתיות וגם לקוד

כל לקוח יכול וצריך למצוא את השותף שמתאים לצרכים שלו

המעבר לענן נושא בחובו יתרונות רבים ובכדי לנצלם בצורה המיטבית יש צורך להכיר אותם. ספקי שירותי ענן תמיד יכירו טוב יותר את היכולות, הן ברמת השירותים והן ברמת התמחור. לרוב הם גם יהיו הראשונים לדעת על כל פיצ’ר חדש לאור העובדה שהם מקבלים עדכונים שוטפים מחברות הענן, ויודעים גם מה מפת הדרכים לשינויים שעשויים להתווסף בתקופה הקרובה

עבודה עם שותף (ספק שירותי ענן מומחה), תייעל את העבודה בענן לחברות המעוניינות להגר מהסביבה הפרטית. בניית התשתית תהיה לפי ההגדרות המומלצות ע”י חברת הענן אל מול הדרישות של כל בעלי העניין בארגון. לכל אחד דרישות שונות, צרכים שונים, מגבלות ותקנים אשר הלקוח מחויב לעבוד לפיהם. בבניית תשתית הענן יש צורך לקחת בחשבון את כל אלו והם גם אמורים להמשיך ולהיות הקווים המנחים בבניית הארכיטקטורה של התשתית והסביבה

בנוסף תכנון נכון של תשתיות יכול לנצל את היתרונות של הענן באופן משמעותי. לדוגמה, בבחירת סוגים שונים של מערכות אחסון לצרכים שונים. מידע “חם” עם צורך בגישה רציפה ותכופה יאוחסן בדיסקים מהירים ומידע שלא דורש גישה בתדירות גבוהה ניתן לאחסן בשירותי אחסון המיועדים לכן (וישנן כמה רמות כאלו), שמחירם נמוך משמעותית. כמו כן, כלי האוטומציה והאוטו-סקיילינג אותם מציע הענן, מספקים יכולת לרכוש שרתים מותאמים יותר אשר יספקו מענה ראוי לעבודה השוטפת אך ברגע של עומס חריג או צורך זמני אחר, יעלו באופן אוטומטי שרתים נוספים בכדי לתמוך מיידית. פרקטיקה זו מבטיחה עבודה רציפה, אך התשלום עבור השרתים שעלו וירדו אוטומטית לפי הצורך, יהיה רק עבור זמן הריצה שלהם בפועל

“שירותים” במקום “שרתים”

אחד היתרונות הבולטים במעבר לענן הינו השירותים המנוהלים. היכולת לצרוך “שירותים” במקום “שרתים” מייעלת באופן משמעותי את העבודה השוטפת, תפעולית ופינסית. לכל חברות הענן יש מגוון שירותים מנוהלים לתחומים רבים כגון

IoT, Data, Storage, Developer tools, Containers, AI+Machine learning, Security, Compute etc..

היכולת של מומחה ענן מטעם השותף להמליץ על היתרונות בשימוש בשרתים מנוהלים, לאחר שחקר והבין את המשמעויות של החלופות אל מול הצורך, היא המפתח להשיג יעילות מקסימאלית עבור האפליקציות וסביבת העבודה בענן

ישנן דוגמאות רבות לערך שמייצר שותף מומחה שמלווה חברות במסע על הענן. שותף זה נשאר תמיד ברקע לייעץ לכל צורך שעולה, אבל בעיקר לבצע אחת לתקופה אופטימיזציה של עלויות. בביצוע תדיר של אופטימיזציה, הלקוח יכול לחסוך עשרות אחוזים בתשלום החודשי השוטף עבור שירותי הענן. הכרות השותף המומחה עם מחירוני חברת הענן והעובדה שהוא מהראשונים שמתעדכנים על כל שינוי בתוכניות התמחור ומשקף זאת ללקוח, מייצר ערך כלכלי מוחשי ומיידי

לשותף מומחה יש את היכולת להתאים ללקוח תוכנית תמחור המתאימה לצרכיו. חברות ללא שותף לרוב לא יוכלו להשיג את אותן התוצאות. מעבר לכך לקוחות אשר עובדים ישירות מול חברת הענן לרוב ישלמו את התעריך הקבוע שהוא הגבוה ביותר לכל שירות, שוטפים יכולים לתת ללקוחות הנחה מהמחירים הללו שתקוזז מהרווחיות שלהם בעסקה. כמו כן, הם גם יכולים להציע ללקוח את תמיכת חברת הענן ללא עלות כחלק מהשירות, את אותה התמיכה על הלקוח לרכוש במידה והוא עובד ישירות מול חברת הענן

אז לפני כל החלטה לצאת למסע אל הענן, בין אם מדובר על חברה גדולה עם מערך מחשוב מפותח או בסטרטאפ בתחילת דרכו, מומלצץ להתייעץ ולבחור את השותף המומחה הנכון

Rapyd’s recruitment billboards that popped out recently on prime locations are another remarkable reminder for the mind-blowing resources invested in the efforts for recruiting top development talent.

Are HR/Talent acquisition/Recruiters/Head hunters being “doomed” to this Sisyphus mission…probably yes at least for the coming year or so. However, is there any way to ease the burden of the rock? Decrease the slope? Survive this never-ending “battle”? Maybe there is.

We should start with challenging some of the paradigms regarding talent recruitment.

We have yet to see this level of challenge. Not so sure? I recall my first year the high-tech industry back on 2000 before he first bubble burst. It was at the center parking area of Herzlyia Pituach at Maskit st. the cars’ windshields were covered by a paper advertisement “If you’re a software developer with three years of experience come work with us for 30,000 ILS a month”, you can draw the fine line from the windshields to the billboards, the challenge of getting top talent is here for a few decades and counting.

We will be able to recruit and preserve our professionals for many years to come. Apparently not. The paradigm that a developer will stay for 5-6 years doesn’t carry its weight, it’s an outcome of endless opportunities, anthropological evolutions (generation Z, millennials…) that narrowed the average life span of a developer’s position to somewhere between 2-3 years, in certain line of expertise like Devops even less. Recent surveys reflected that the share of developers that left their jobs doubled itself from 2008 up to 15% on 2017 and estimated to excel the 20’s at the start of 2021.

However, there are new factors: Covid-19 boost to Digital Transformation, propelled the already “smoking” Israeli high-tech ecosystem which is being reflected by an outstanding number of around 50 Unicorns, 400% increase from 2019. More jobs, more money, many more deadlines. On the other hand, remote & hybrid working models enlarged the developers’ potential working radius and enabled recruitment of peripheral habitants to companies in mid-town Tel-Aviv and co.

Bottom line, I don’t envy my talent acquisitions friends.

Dan Heath in his book ” Upstream, the quest to solve problems before they happen” addresses solutions for this type of challenges where one should exercise an “Upstream mindset” that will enable him to proactively diminish a problem and not just continuously react to its outcomes.

It’s a downstream state of mind to hectically source potential employees and offer them the moon and stars and then start looking for their replacements one or two years later, whereas it’s an Upstream activity to shift our resources to the roots of this situation. In order to analyze it, we should focus on one of or the most crucial factor, no company wants to “grow” developers, everybody wants and experienced developer that will provide immediate impact on their code source. After all a major investment usually reflects grave stakeholders’ pressure and tight release plans. Upstream thinking will point us to bridging the preliminary and biggest gap of migrating an entry level developer to an efficient productive, somewhat experienced contributor. Implementing the right planning and resources we can create a quicker “Time to Productivity”.

We exercised this way of thinking in CodeValue’s bootcamps. 10-12 entry level developers, fresh academic graduates, that we turned into smooth “coding machines”. The process starts with Bootcamp’s screening project which is different than the regular ones since we’re not looking for efficient/clean code but for top university alumni with sharp minds, positive attitude and extreme self-learning skills. To the few that passed the process we provided targeted, multi exercised training by our elite architects. After conclusion of this phase, we allocated them to projects in which a Senior Codevalue developer led and mentored them. These bootcamps enable us to cut “time to productivity” and provide quality code contributors to our clients. 

Throughout this time, we continued with most of our regular recruiting efforts, since the other part of the equation is keeping the fragile equilibrium between Bootcamp graduates and senior developers.

The cynical person will ask, but just four paragraphs above you wrote that other companies will target these developers, that’s correct however with lower kick off salaries and the quicker time to productivity eventually increase the net cost of contribution of each developer and with the right contracting, engagement and pin pointed employee preservation we can pick the “fights” for the developers that we best fit our DNA and standards.

And in a wider high-tech ecosystem perspective addition of dozens and hundreds of capable developers may somewhat flatten the unbalanced supply and demand curves and hopefully return some sanity to the Israeli high-tech scene and a few hours of relief to the recruiting personnel.

Do you want to scale-up your development team, click for more information on CodeValue’s Dedicated Bootcamps

Published by Hanan Zakai

Technology Division Manager @CodeValue

Recently, we hosted a half-day online event where our experts shared their understanding of what Microservices are all about.

Sometimes it feels like everybody is creating Microservices Architectures. Everyone’s building a new system with Microservices, decomposing old monoliths, and generally giving us the feeling that Microservices is the only way to go. But is it the only option? What should we consider when approaching Microservices? When should or shouldn’t we use Microservices? And if we do decide to take the approach, how should we handle Microservices?

In this half-day online event Alon, Eran & Tomer shared their understanding of what Microservices are all about, when we should use them, what we should avoid, and how to implement them correctly. If you’re a novice to Microservices, or even if you’ve already heard quite a bit about them, you’ll find these talks beneficial. This workshop was intended for decision-makers, software architects, DevOps architects, senior developers, and senior DevOps engineers.

---

To Microservice or Not to Microservice? How?

Alon Fliess, Chief Architect @CodeValue

Do more with less, the pain of the modern architect. High cohesion & low coupling, high availability & scale, ease of DevOps. Our systems need to support all these quality attributes, while providing more functionality with less resources. We need to be agile, we need to embrace changes, we need to have a better way! Micro-Service-Architecture (MSA) promises to bring cure to the architect’s pains, but does it really deliver?

This lecture presents the essence of MSA, how does it answer the main concerns of modern distributed systems, how to get started, how to migrate current solutions to MSA by adopting an evolution migration path. What to be careful about and the signs that we are on the right track. We will talk about SA evolution, the CAP theorem and eventual consistency, MSA principles, hosting. containers, versioning, orchestrators & decupling business processes. By the end of this lecture, the participant will have a better understanding of why, when, and how to embrace MSA.

---

6 Lessons I Learned on My Journey from Monolith to Microservices

Eran Stiller, CTO @CodeValue

For the past couple of years, Microservices is all the rage. We want to use Microservices, we want to decompose into Microservices, and we want Microservices to be a part of our world. While modern tools and platforms such as Docker, Kubernetes, Service Mesh, and the public cloud help in implementing and maintaining such systems, the reality is that many fail even before the first line of code was written.

This can happen for many reasons; Perhaps you chose a Microservices architecture for the wrong reasons? Maybe the organization wasn’t ready for it? Or just possibly – perhaps the proposed architecture didn’t embrace the true meaning of Microservices?

As the CTO of CodeValue, I get to tackle these questions a lot. Join me in this session as I provide my perspective on transitioning from Monolith to Microservices through lessons learned in the real world while architecting and implementing multiple Microservices based software systems at various customers.

---

A Recipe for Pickled Microservices

Tomer Shamam, Senior Software Architect @CodeValue

Microservices are actually small and self deployed apps which can be distributed and scaled. The best recipe to “pickle” micro-services and harness their true power, is to isolate them from others, putting them inside a container. A container is a standard unit of deployment that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.

In this session, we will discuss app containers in general and we will learn how easy and beneficial is to containerize micro-services using Docker, the lead app container solution in the market.

---

Panel – Microservices Open Q&A

Alon Fliess, Eran Stiller & Tomer Shamam discuss and answer Microservices-related questions raised from the audience.

---

Want to stay up to date? Follow us on Social Media

One full day, over 500 participants, 3 tracks, 13 lectures, and one cloud experts panel!
Wow, we had a blast.

The software development world is developing at a tremendous pace. New technologies and platforms are abundant, and things that were brand new a year ago sometimes suddenly seem like ancient history. The software architect’s job is to figure out how to best use these technologies and platforms to his/her advantage, and that job is getting harder and harder. At Architecture Next 2020 we discussed revolutionary concepts and tools and demonstrated how they can be applied towards making your next software system a better one.

Due to Coronavirus related restrictions, this year’s conference, held for the third consecutive year, was all virtual. But as usual, was packed with great content and insightful speakers.

General assembly

The conference day was launched with an introduction to CodeValue’s new CEO, Tali Shem Tov. Tali delivered a brief talk about models & technology of the new era.

The keynote session was delivered by guest speaker Magnus Mårtensson the Founder & CEO of Loftysoft, a Microsoft Azure Most Valuable Professional and a Microsoft Regional Director. Based on his extensive experience of helping numerous (small to enterprise) customers, Magnus highlighted some areas with important learnings and common challenges to target early optimization paths on the way to the cloud.

Keynote: The Cloud challenge is more than just technical – people are involved

Magnus Mårtensson: The Cloud challenge is more than just technical – people are involved from CodeValue

Upon completion of the opening lecture, the day was divided into 3 different tracks:

---

Executive Track

The first session on this track was given by Alon Fliess, Chief Architect at CodeValue (MVP & Microsoft Regional Director). In his session, Alon elaborated on the essence of the APM systems, the good, the bad, and the vision about their future.

APM – What Is It, and Why Do I Need It?

Alon Fliess: APM – What Is It, and Why Do I Need It? – Architecture Next 20 from CodeValue

---

The second session was given by Erez Pedro, co-founder and head of product & UI/UX at CodeValue. In his talk, Erez demonstrated how together we evolve the system from a technical device to a full product in a process including analysis, design with rapid prototyping.

Product Thinking 101

Eerez Pedro: Product thinking 101 – Architecture Next from CodeValue

---

Nir Dobovizk, a Software Architect and a Consultant at CodeValue gave the third session on this track, in which he told us the tragic story of the microservices-based, modular, fully automatic, next-generation, totally buzzword-compliant, multi-satellite ground station that wasn’t.

In Space, No One Can Hear Microservices Scream – a Microservices Failure Case Study

Nir Doboviski: In Space No One Can Hear Microservices Scream – a Microservices Failure Case Study – Architecture Next from CodeValue

---

To conclude the Executive track we had the pleasure to hear Alex Pshul, a software architect, consultant, speaker, and tech freak. Alex shared with us what can be learned from testing the execution of 300K messages per second in a totally serverless system.

What We Learned by Testing Execution of 300K Messages/Min in a Serverless IoT System

Alex Pshul: What We Learned by Testing Execution of 300K Messages/Min in a Serverless IoT System – Architecture Next 20 from CodeValue

---

Cloud & Back-End Track

To kick off the Cloud & Back-end track, Michael Donkhin a Software Architect at CodeValue, talked about all things Java. He started with a retrospective of the Java platform history. Next, was a review of some of the most popular frameworks around Java. And finally, Michael concluded with a review of ongoing efforts to improve the platform further and extend its reach, like project Valhalla and GraalVM. 

Java Turns 25 – How Is It Faring and What Is Yet to Come

Michael Donkhin: Java Turns 25 – How Is It Faring and What Is Yet to Come Arch next2020 from CodeValue

---

The second session in this track was given by CodeValue’s Co-Founder & CTO Eran Stiller. Eran is recognized as a Microsoft Most Valuable Professional (MVP) on Microsoft Azure since 2016 and as a Microsoft Regional Director (MRD) since 2018. In his talk, Eran reviewed today’s most popular API formats and their relative strengths and weaknesses. From REST, through OpenAPI, via gRPC and to the rising star of AsyncAPI. 

API Design in the Modern Era

Eran Stiller: API design in the modern era – architecture next 2020 from CodeValue

---

Following Eran, Moaid Hathot a prominent Software Consultant at CodeValue. Moaid introduced Dapr and demonstrated how we can use it to build a distributed, cloud-native, microservices application using various programming languages and frameworks, that can run virtually anywhere.

Dapr: The Glue To Your Microservices

Moaid Hathot: Dapr the glue to your microservices – Architecture Next 20 from CodeValue

---

Ronen Levinson is a DevOps Engineer and consultant at CodeValue. Ronen concluded the Cloud & Back-End track with a discussion about what is OPA, He explored OPAs’ integrations with all the levels of the cloud-native stack, along with on-stage demos.

Centralized Policy Governance With OPA

Ronen Levinson: Unified policy enforcement with opa – Architecture Next 20 from CodeValue

---

Front-End Track

Amir Zuker, a Co-Founder of CodeValue and its Web and Mobile division leader, is a senior software architect specializing in .NET and Web-related toolchain and technology stack. Amir opened the track with a session covering the emergence of WebAssembly into the app world while using Blazor and C#.

Building Web Apps With WebAssembly and Blazor

Amir Zuker: Building web apps with web assembly and blazor – Architecture Next 20 from CodeValue

---

The second session in this track by Vitali Zaidman, a Web Architect and Blogger from Welldone Software, demystified the different approaches and discussed the trade-offs while exploring real-world examples.

Do You Need Server Side Rendering? What Are The Alternatives?

Vitali zaidman Do You Need Server Side Rendering? What Are The Alternatives? from CodeValue

---

Eyal Ellenbogen was our third speaker on that track. Eyal is a Web Developer and Architect at CodeValue. In his session, he explored the process and the decisions involved in building a UI component toolkit and how to get it right the first time.

Building a UI Foundation for Scalability

Eyal Ellenbogen: Building a UI Foundation for Scalability – Architecture Next 20 from CodeValue

---

Ending this track was Vered Flis, a Senior Software Engineer at CodeValue. In her session, she tackled the big questions head-on and unravel different approaches and practices that will assist you in writing highly performant web apps as is expected today.

Because Performance Matters!

Vered Flis: Because performance matters! Architecture Next 20 from CodeValue

---

Panel – Public Cloud, Hybrid Cloud, Israeli Cloud, Microservices, PaaS, SaaS, and Everything in Between

The topping on the ice cream was the Cloud experts panel, where our own cloud experts: Alon, Eran, Amir & Hanan hosted Tomer Simon (Ph.D.) the National Technology Officer in Microsoft Israel. in the panel, the experts talked about all things Cloud and answered questions such as: How should you approach the move to the cloud? What are the risks of an on-prem requirement? Should you use PaaS & SaaS, or is IaaS king? Which cloud vendor should you use? And many more pressing issues.

We are here for you

Need Consulting or development services? we’re here for you .

Thank you all who attended our webinar, delivered by Amir Zuker on Micro Frontends – “extending the microservice idea to frontend development”.

So, what does it really mean? Is it just another hype? should you consider it? How should one approach it?

These are just some of the questions one might ask when presented with this notion. Long story short – it’s possible! However, it is not for everyone, and especially to the full degree.

View this session where Amir demystifies the concept of micro frontends and tackles the subject head-on.

Micro Frontends Pattern – Replay

We are here for you

Need Consulting or development services? we’re here for you .

Thank you all who attended our first (of many to come) webinar, delivered by Vitali Zaidman on Advanced React – Virtual DOM and Performance

The virtual DOM is what we generate through the renders of React components. But React is designed in a way where we don’t care about what happens as a result of these renders. This lecture aims to explain the relationships between different React elements- a concept that would help us to reveal React patterns where performance might be an issue. We would later show how to avoid running into these performance issues.

Advanced React – Virtual DOM and Performance – Presentation

Advanced React – Virtual DOM and Performance – Replay

We are here for you

Need Consulting or development services? we’re here for you .

Hello Everyone!

In my previous post, we started discussing the deployment of Infrastructure to Azure using Terraform and Azure DevOps. If you haven’t done so already, please read this post first.

In this post, we will cover the setup of the components and create our first pipeline to test our code!

GitHub Repository Configuration

My code is on GitHub. We will connect the GitHub repo with Azure DevOps pipelines engine in order to build and deploy our Terraform infrastructure code.

At a high level, this is the flow of code in our repository, between branches:

• Our features, enhancements, etc. will be done on the pr branch. This can be called feature branch or any other descriptive name
• On this branch we will work locally, validating the terraform code, without actual deployment
• Once we feel comfortable with the result, we will create a pull request (thus the name of the branch, pr) from the pr branch to the dev branch
• To validate the pull request and approve the merge, we will run a pipeline in Azure DevOps

• Once merged, we will execute another pipeline, that builds the code from the updated dev branch and creates a terraform plan artifact

• We will deploy the terraform plan to Azure using the validated artifact and Azure DevOps release pipeline

• Once the code was successfully deployed to Azure, we will create another merge from dev to master, tag the code and create a release on GitHub, thus assuring only validated code exists on the master branch and giving us a checkpoint to go back to in case we need to in the future.

• Lastly, we will deploy the validated code to other environments, such as qa, staging and production

---

Now, let’s head over to Azure DevOps and start preparing our pipeline, so we can connect it to our branches. We will add some code later.

Connect Azure Key Vault to Azure DevOps

In the previous post we created a service principle and Key Vault in Azure and created several secrets to hold the sensitive information (SPN id, secret, etc.)

The concept is to use secrets from Key Vault as pipeline variables in our Azure DevOps pipeline. Let’s connect Azure Key Vault with Azure DevOps to accomplish that.

For a complete overview of variable groups and Azure Key Vault, read this. The short version:

1. Go to Variable Groups in your project
2. Toggle Link Secrets from an Azure Key Vault…
3. Choose you Azure Subscription and the previously created Key Vault. If you haven’t setup a connection to Azure yet, you can configure one here
4. Once connected, choose all secrets to be used as variables

Create our “PR-Validation” Pipeline

This pipeline will be used to validate our pull request before we merge our code from the pr branch into the dev branch.

• In Azure DevOps, go to pipelines and create a new pipeline
• Choose GitHub, authenticate if needed and choose your repository
• Click on starter pipeline to get a basic template, modify the name to azure-pipelines-pr.yml and click save and run
• This is a simple “hello world” pipeline that we will modify to meet our needs
• Once completed, edit the pipeline and insert the following text:

---

Before we continue with the configuration, I would like to pause for a moment and explain the pipeline and the logic behind it, as we will use it throughout our project.

—

name: Build-$(Build.BuildId)

trigger: none
pr: [dev]

pool:
  vmImage: 'ubuntu-latest'

In the above section we define the build name to use the BuildId.

This will give us unique name for each build and we will use it later in release and tagging as well for complete end-to-end traceability (Basically, we can track back from a deployed resource in production all they way to the commit that created it).

We also set the build to trigger whenever there is a pull request to the dev branch and nothing but that.

Lastly, we define our build agent to be taken from a pool of ubuntu machines.

—

steps:
- task: TerraformInstaller@0
  displayName: 'Install Terraform version $(TF-Version)'
  inputs:
    terraformVersion: '$(TF-Version)'
- script: terraform init -get=true -upgrade=true -backend-config='storage_account_name=$(sa-name)' -backend-config='container_name=$(blob-name)' -backend-config='access_key=$(sa-key)' -backend-config='key=$(key)'
  workingDirectory: '$(Build.SourcesDirectory)'
  displayName: 'Terraform Init'

The above section has 2 simple steps:

1. Install Terraform on the build agent (I haven’t explained the Terraform code yet, and we will dive deeper into it later)
2. Run a shell script that initialize terraform with Azure backend

The steps are generic as possible. This means we’re not “tied” to Azure DevOps and we can implement the same flow in any CI engine of our choice (Jenkins / GitHub Actions / etc.) with small modifications:

—

- script: terraform workspace select '$(Dev-WS)' || terraform workspace new '$(Dev-WS)'
  workingDirectory: '$(Build.SourcesDirectory)'
  displayName: 'Switch to Environment $(Dev-WS)'

In the above section I want to emphasise the use of Terraform Workspaces.

Without diving too deep, workspaces gives us the ability to create multiple instances of environments from single code. Meaning, the code is a template to create a given environment and workspace will allow us to use the same code and create dev, qa, stg & prod environments from it.

---

Variables

As you can see, we have severals variables we use in the pipeline, all can be identified by the syntax $(variable). Let’s configure the connection to our previously-created variable group to define values for these variables.

• Click on the 3 dots and triggers to configure input for those variables

• In the opened window, go to the variables tab and then to variable groups
• Click on link variable group and connect the one you created earlier DevOps-KV
• You should now have values for the following variables in your pipeline:
  • sa-name
  • blob-name
  • sa-key
  • subscription-id
  • client-id
  • client-secret
  • tenant-id
  • repo-name
  • repo-username
  • repo-password
• If any of the above doesn’t exist in Key Vault, you should go ahead and create them and then make sure you connect them to Azure DevOps, as I explained earlier
• Additionally, you should create another variable group to hold other non-sensitive variables such as TF-Version (value=0.12.17), Dev-WS (value=dev), etc.
• Note you don’t need to create values for any variable that starts with $(Build.) as it is a system pre-defined variable. You can read all about these variables here
• Rename the pipeline to Terraform-PR and click save and queue. Your pipeline will likely fail as we didn’t put any Terraform code in our repository. This is fine as we will do that soon

Connect our pipeline to validate code merge

The goal is to test code before we merge it. Let’s head over to GitHub to make that connection.

• Go to your repository in GitHub and create a new branch from the master branch and name it dev
• Go to settings -> branches -> add rule

• For an in-depth explanation about GitHub protection, see here
• For our use case, we will configure the following:
  • Name pattern: dev
  • Protect matching branches: check require status check to pass before merging and choose the pipeline from the list. It should auto-appear in the list since we run in against our repository in the previous step

Recap

In this post, we learned:

• How to connect Azure Key Vault to Azure DevOps and use secrets from Key Vault as parameters in our Build Pipeline
• Configure pipeline-as-code in Azure DevOps using YAML file syntax
• How to connect GitHub repository to Azure DevOps and protect a GitHub branch from merging verified code

What do you think about the process so far? Were you able to test it for yourself? Leave us a comment or DM me on Twitter and share your thoughts!

In the next post we will dive a deeper and start deploying our infrastructure code into Azure! If you’re into Kubernetes and Terraform, be sure to follow our blog as exciting updates are just around the corner!