The significance of microservices architecture
and cloud-native approaches for business growth

In June, CodeNOW joined the Cloud Computing Conference in Prague. Our CEO Petr Svoboda, delivered a compelling speech on microservices and their transformative potential. Here are the main outcomes from his presentation.
‍
‍

What is a domain?

‍A domain is a set of things, defined by criteria that you choose. You might create a domain based on shapes or colors, and these domains can overlap. A familiar example is the business domain, where different elements interact within a company’s processes.

Consider a scenario within a company: marketing, operations, and services all interact with what they refer to as a "customer." However, when you look deeper, and you'll find that in marketing, this "customer" is often called a "lead"—someone who isn’t a customer yet but might become one. This highlights how different domains use specific terminology and criteria that shape their operations. For instance, rather than having one customer with 10,000 attributes, you might have three distinct types of customers within different domains, each with unique attributes.

From a broader perspective, you structure a company based on several business domains. Everything in a business may seem perfectly aligned. However, the reality in software is often different. A CRM system stores customer data, and KYC (know your customer) data is also kept there. This leads to integration problems when selling products and pulling data from multiple systems.

The key issue is coordination. Implementing new features requires touching multiple IT systems, which kills productivity. To improve this, business domains and IT systems should be aligned one-to-one. This way, any changes in a business domain can be made within a single IT system, reducing complexity and improving efficiency. The solution is to break down large systems into microservices, each handling specific business needs within their domain.
‍

How Software is Made

Well-executed projects should have an "Independent Value Stream." For this chain to work effectively, it needs to align closely with the specific area of focus or domain. If the process spans multiple business domains horizontally, it might look good on paper but won't be very practical. Vertical alignment is important here. This approach allows teams to concentrate on achieving specific outcomes while having full control over data, business functions, stakeholders, budget, and day-to-day operations. By operating independently within their domain, teams can avoid issues like being unable to test due to accidental data deletions by teams in other domains.

Empowering teams with the right support throughout the development cycle is essential. This includes considering whether IT operations should be centralized or decentralized and determining the tools developers use and where they operate. Relying solely on centralized tools often leads to bottlenecks. Developers end up creating tickets in systems like ServiceNow or Jira, waiting on essential tasks like creating new databases or granting network access. This backlog competes with urgent production issues, where customer satisfaction is at stake. These delays can be costly.
‍

Domains vs Microservice

Can a single domain have multiple microservices? Absolutely.

• Granular Functionality
• Independent Scaling
• Deployment Flexibility
• Technology Heterogeneity
• Fault Isolation

The way and reason for structuring microservices change over time. One rule to remember is: don't make decisions until you understand the problem well.

When planning microservices, source them based on business or technological reasons. For example, if one part scales independently, it justifies its own microservice.

Technological heterogeneity - Imagine a company excited to introduce AI into its operations. They hire a vendor to build a microservice for a chatbot, aiming to automate 30% of their services using ChatGPT. The plan sounds perfect until they realize their team isn't skilled in the vendor's chosen technology Python, which differs from their usual Java environment. To adapt, they modify the microservice to support both Python and Java within its container.

Fault isolation. Some components fail more often than others. Microservices must fulfill their promises independently, unlike traditional service-oriented architectures that often fail due to backend dependencies. Each microservice contains the necessary data to function autonomously, ensuring that even if one fails, it doesn't bring down the whole system. This isolation is a key reason for segmenting functionalities into microservices.
‍

Size and Responsibility of a Microservice

A microservice should have a single responsibility. This approach ensures that individual team members are replaceable, minimizing the onboarding time for new developers. Microservices must speak a common language within their scope. Mixing terminologies within a microservice, such as referring to a customer in multiple contexts, should be avoided. Microservices must own their state and be able to function autonomously.

Cloud infrastructure is fluid, with API addresses frequently changing. Microservices should handle this by being loosely coupled, minimizing dependency on constant connections, which are prone to failures.

Development teams should be empowered with self-service capabilities and be accountable for their microservices. They should have the autonomy to manage their clusters and be responsible for their deployments. Knowledge sharing within the organization is important to avoid redundant learning and to facilitate smoother transitions.

Allowing teams to experiment is essential. Rushing into production with a new microservice architecture without adequate experience leads to costly mistakes. Provide teams with demo applications and shared knowledge bases to standardize practices and accelerate learning.

By following these principles, teams can effectively transition to and manage a microservice architecture, aligning business and technology goals for greater agility and resilience.
‍

Organizing Teams in a Microservices Architecture

How to organize teams in such architecture? There's a methodology called Team Topologies that talks about not only achieving the desired state but also managing organizational structure changes in that state. This transition can take years or even decades for some entities. It’s important to leverage platforms wherever possible so developers aren't reinventing the code. For example, if there’s a service discovery solution available from a cloud provider, use it instead of having ten teams develop their own versions. Shared services should be utilized across the organization.
‍

Why Microservices?

Microservices are adopted to help organizations deliver software faster, more frequently, with higher quality, and to improve the developers' work experience. Additionally, they enhance the organization’s resilience to change.

However, what isn't measured cannot be managed. While outsourcing is effective for infrastructure-level tasks, there are critical aspects that cannot be outsourced: the architectural vision, software delivery processes, team organization, product and service design for end-users, and company culture.

Continuous improvement in collaboration, measuring outcomes, and refining processes are essential. The significant shift to cloud-based solutions requires a strong focus on managing both people and systems. By focusing on these aspects, organizations can successfully manage the complexities of transitioning to a microservices architecture and improve their overall software delivery capabilities.

Does everything need to be in microservices?

NO, it doesn’t.

If something is stable, keep it in the monolith and focus on other parts of the business that change more frequently. Microservices should be well-testable and loosely coupled, connected to the rest of the system asynchronously. Permanent connections should be independent because cloud infrastructure often fails.

‍

CodeNOW

We developed CodeNOW, a multi-cloud, hybrid cloud platform, to help developers overcome the complexities of modern software development. Rescaling development efforts can be both costly and challenging, but with CodeNOW, we aim to make this transition smoother and more efficient. With the right tools and support, your team can achieve greater agility, higher quality, and faster delivery, ultimately driving your business forward.

For a real use case of how we helped our client, Packeta, transform from a monolith to microservices -  here.

To watch Petr Svoboda's full presentation on Cloud Computing, click here.