In June, CodeNOW joined the Cloud Computing Conference in Prague. Our CEO, Petr Svoboda, delivered a compelling speech on microservices architecture, cloud-native development, and their transformative potential for business growth. 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
Successful projects rely on the concept of an independent value stream, which ensures that each team operates with autonomy and focus. For a value stream to deliver optimal results, it must align closely with a specific business domain. While horizontal processes spanning multiple domains may look structured on paper, they often create practical challenges.
Prioritizing vertical alignment allows teams to focus on clear outcomes while maintaining full control over data, business functions, stakeholders, budgets, and daily operations. By operating independently within their domain, teams can prevent common issues, such as testing disruptions caused by accidental data changes from other teams.
This domain-focused approach not only improves efficiency and accountability but also strengthens the overall execution of complex projects.
Empowering development teams with proper support throughout the software development lifecycle (SDLC) is critical for efficiency and productivity. This includes evaluating whether IT operations should be centralized or decentralized, as well as choosing the right tools and determining where developers operate.
Over-reliance on centralized tools can create bottlenecks. Developers may spend valuable time creating tickets in systems like ServiceNow or Jira, waiting for essential tasks such as database provisioning or network access. These delays often compete with urgent production issues, directly impacting customer satisfaction and business outcomes.
By optimizing IT operations and providing teams with autonomy and the right resources, organizations can reduce operational bottlenecks, accelerate development, and minimize costly delays.
Domains vs. Microservices: Structuring for Scalability and Resilience
Can a single domain have multiple microservices? Absolutely. Structuring microservices within a domain enables teams to achieve granular functionality, independent scaling, deployment flexibility, technology heterogeneity, and fault isolation.
The approach to microservices evolves over time, and one key principle is: don’t make structural decisions until you fully understand the problem. When planning microservices, align them with business or technological needs. For example, a component that requires independent scaling may justify its own microservice.
Technological Heterogeneity
Consider a company introducing AI-driven automation. They hire a vendor to build a microservice for a chatbot using Python, aiming to automate 30% of customer services with ChatGPT. The initial plan seems ideal until the in-house team realizes their expertise is primarily in Java. To adapt, the microservice is modified to support both Python and Java within its container, demonstrating the importance of technology flexibility in microservices architecture.
Fault Isolation
Certain components fail more frequently than others. Unlike traditional service-oriented architectures (SOA), microservices are designed to operate independently, containing all necessary data and functionality within their boundaries. This fault isolation ensures that the failure of one microservice does not compromise the entire system, making it a core reason for segmenting applications into microservices.
By aligning microservices with domains, businesses can optimize scalability, resilience, and overall efficiency while maintaining flexibility in technology choices.
Size and Responsibility of a Microservice
A microservice should have a single responsibility, ensuring clarity in its purpose and making team members easily replaceable. This approach reduces onboarding time for new developers and simplifies maintenance. Within its scope, a microservice must use a consistent terminology—for example, avoiding multiple interpretations of a “customer” across contexts.
Each microservice should own its state and operate autonomously. In dynamic cloud environments, where API addresses frequently change, microservices must be loosely coupled, reducing dependencies on constant connections that are prone to failure.
Empowering Development Teams
Development teams should be empowered with self-service capabilities and take full accountability for their microservices. They should manage their clusters, oversee deployments, and contribute to knowledge sharing across the organization to prevent redundant learning and enable smoother transitions.
Encouraging Safe Experimentation
Allowing teams to experiment with microservices in controlled environments is critical. Rushing into production without sufficient experience can lead to costly mistakes. Providing demo applications, shared knowledge bases, and standardized practices accelerates learning while maintaining operational safety.
By adhering to these principles, organizations can effectively adopt and manage a microservice architecture, aligning business and technology goals to achieve greater agility, resilience, and scalability.
Organizing Teams in a Microservice Architecture
Effective team organization is crucial in a microservice architecture. One proven methodology is Team Topologies, which focuses not only on achieving the desired system state but also on managing organizational structure changes to support that state. For large organizations, this transition can span years or even decades.
To maximize efficiency, teams should leverage existing platforms and shared services wherever possible, avoiding redundant development. For example, if a cloud provider offers a service discovery solution, teams should adopt it rather than having multiple teams build separate implementations. Centralizing and standardizing shared services across the organization ensures consistency, reduces technical debt, and allows developers to focus on delivering business value rather than reinventing the wheel.
Why Microservices?
Organizations adopt microservices architecture to deliver software faster, more frequently, and with higher quality, while also improving the developer experience. Beyond speed, microservices increase organizational resilience, enabling teams to adapt quickly to change.
However, effective adoption requires measurement: what isn’t measured cannot be managed. While outsourcing can handle infrastructure-level tasks, critical elements must remain in-house, including architectural vision, software delivery processes, team organization, product and service design, and company culture.
Continuous improvement is essential. This involves fostering collaboration, measuring outcomes, and refining processes over time. With the growing shift to cloud-based solutions, organizations must carefully manage both people and systems. By focusing on these areas, businesses can successfully navigate the complexities of transitioning to a microservices architecture, improving overall software delivery capabilities and achieving long-term agility.
Does Everything Need to Be in Microservices?
No, not everything needs to be converted into microservices. Stable parts of your system can remain in a monolithic architecture, allowing teams to focus on areas of the business that change more frequently.
Key principles for microservices:
- Well-testable: Each microservice should be independently testable.
- Loosely coupled: Microservices should communicate asynchronously, minimizing dependencies.
- Resilient to failures: Permanent connections should be independent, as cloud infrastructure is inherently dynamic and can fail.
By selectively applying microservices where flexibility and scalability are needed, organizations can balance efficiency with system stability.
Introducing CodeNOW: Simplifying Modern Software Development
We developed CodeNOW, a multi-cloud and hybrid cloud platform, to help developers navigate the complexities of modern software development. Scaling development efforts can be costly and challenging, but CodeNOW streamlines this process, providing the tools and support teams need to achieve:
- Greater agility in development and deployment
- Higher software quality through standardized processes
- Faster delivery of features and services
By leveraging CodeNOW, organizations can accelerate the transition from monolithic systems to microservices architectures, improving operational efficiency and driving business growth.
For a real-world example, see how we helped Packeta transform from a monolith to microservices, achieving faster releases and more scalable development processes- here.
To watch Petr Svoboda's full presentation on Cloud Computing, click here.
