When Should I Use Microservices?
- The Kalix Team at Lightbend
- 9 Jan 2023,
- 9 minute read
By design, microservices divide large systems into loosely coupled but highly cohesive services. Each microservice provides a small amount of functionality and can deploy and scale independently without impacting others.
The goal of microservices is to deliver quality software faster. In today’s age of rapid technological innovation and widespread adoption of cloud technology, decoupling your monolith into microservices can be a significant step toward digital transformation.
But although this strategy is a resourceful investment in agility, it requires high skill, effort, and discipline when it comes to management and orchestration. As with any investment, it’s essential to understand the risks and merits concerning your business goals. This article will walk you through what microservices do well, their challenges, and whether they’re right for you.
When Is It Time for Microservices?
In developing small to medium web applications, monolithic architectures have many advantages. They can quickly onboard developers, manage, and deploy as it’s just a single application made with one language and library.
However, with an increase in size, age and complexity, it becomes difficult to understand and modify without incident. Onboarding times for new team members are longer, and further changes can often break the app, requiring increasing dependency between teams. Development speed slows, and performance dips due to increasing memory, storage, and processing demands on the same hardware. Taking advantage of third-party offerings might take a while or be impossible to integrate with old languages and libraries. Testing might become infrequent and exhaustive due to a concern about not breaking the application.
In contrast, migrating to a microservices application architecture allows you to decouple a monolith into several smaller, independent services. These services can be deployed as virtual processes or as self-managed containers on servers, in a managed container platform as a service (PaaS), in a managed serverless container, as pods in an orchestrator like Kubernetes, or as serverless functions.
Of particular note is the PaaS implementation, which makes it possible to leave much of the operation and deployment of microservices to a provider’s infrastructure. For example, Lightbend’s Kalix Serverless PaaS provides a unifying application layer that pulls together all necessary pieces, including databases, message brokers, memory caches, service meshes, and more, into a unified programming model for the cloud and edge.
Unlike a monolith application, each microservice can be developed, deployed, and scaled separately—resulting in faster development and improved application performance. Regardless of the distributed nature of microservices across a network and virtual instances, effective communication among these services is possible with REST APIs, Function as a Service (FaaS), gRPC, and asynchronous messaging. Because microservices are platform agnostic, developers can build on various platforms in our preferred language.
What Microservices Do Well
There are many benefits of microservices architecture:
- Modularization: The division of applications into interchangeable modules that can be brought into production individually and independently. The best way to achieve this is to deploy each service as a lightweight, platform-agnostic virtual machine, such as Docker containers or individual processes.
- Bounded contexts or business units: The microservice is a collection of related business functionalities converted into a single business capability implemented as a service.
- Decentralization: The technologies that power microservices architecture favor the decentralization of databases and still function statefully and synched with all services. The developer can also use data structures that make sense without compromising to accommodate other services and teams.
- Scaling: With the help of orchestrators like Kubernetes, managing memory and processing capacity is easier with microservices. We can anticipate CPU and memory consumption and set a resource limit. While running, we can respond to a sudden spike in demand with horizontal scaling. In this case, it means increasing the number of pods to meet demand without downtime for others.
- Size: A well-designed microservice should not be so large that it can’t be easily replaced, understood by a single developer, or maintained by a team of fewer than eight people.
- Platform agnostic: Microservices can be deployed on any operating system and works in many languages.
- Reusable: The development code is templated and reusable.
- Fault-tolerant: Because of the isolation of data in microservices from each other, failure can occur without a service-wide shutdown. Even if the application servers that host these services are targeted, redundancy measures in place can mitigate downtime duration. Note also that because microservices are lightweight, startup time on another machine isn’t lengthy.
- Robust testing: Microservices provide the flexibility to run frequent and rigorous reliability testing that helps us work out kinks in production.
- Continuous delivery: The agility of software delivery on a microservice is its main selling point.
Microservices is a bit like a BMW. There’s some buzz about it. It looks nice, it's powerful, and it has a global following. However, when you purchase one, you realize it requires special knowledge and tooling for even the most mundane maintenance or repair tasks.
In a 2021 article, Gartner reported a 42 percent plunge in mentions of “microservices architecture.” While reduced hype doesn’t have to mean something bad about microservices, Statista reports the global adoption of microservices at 34 percent and partial adoption at 37 percent for 2021 from a survey of 4,294 respondents.
The truth is that properly designed and implemented microservices can be the key to your enterprise's digital transformation. However, there is a range of challenges that stand in the way of success.
The operation of a microservices system can require more effort than running a monolith. By its nature, microservices run over a distributed architecture that involves communication with some network resources —data centers, servers, clusters, meshes, and fellow services over a larger area. The cloud provider might be more concerned about infrastructure availability, interconnectivity, and capital expenditure. Still, as the consumer, you must worry about the connections you have configured within your provisioned servers, clusters, meshes, and services.
Therefore, you may need to build your microservice with some level of skill and foresight that caters to all kinds of variables that can impact performance and availability. For example, this might require caching data locally or implementing stateless transactions for faster transaction volume and less overhead. It might mean load balancing for routine temporary fluctuations in demand or outright scaling for longer. You also want to provide observability and management for your microservice system, alerting you when certain service level thresholds are exceeded.
Microservices still run on hardware connected by a network, so a network outage or disruption of any kind will interfere with business operations. However, on-cloud architecture and redundancy can mitigate this risk.
Transitioning from a monolith system to a distributed one introduces latency that could cause communication speeds in the network to lag or fail. You may decide to address this via vertical scaling by adding more system resources, CPU, and memory, or adopt horizontal scaling by creating replicas of the microservice experiencing a bottleneck.
If a microservice that hundreds of others depend on requires API modification, it can become a logistical nightmare, even if documentation exists.
Most microservices are container images of software that can have various dependencies on prebuilt external components. Naturally, this predisposes one to vulnerabilities directly in these components or the software supply chain of systems, processes, and people involved. However, you can mitigate risks through automated vulnerability scanning tools, compliance-as-code-tools, and an insistence on a software bill of materials (SBOM) from software vendors.
Are Microservices Right for Me?
Before investing in microservices, ask yourself the following questions.
Do I Plan to Scale?
Microservices are ideal for horizontally scaling your workload to meet spikes in demand without having to make destructive changes to your architecture. Before startup, you can also scale over or under the default CPU and memory allocations for your pod and container.
Do I Want to Deploy with Zero Downtime?
Zero downtime microservice deployments lead to increased company productivity, higher revenue, and respectability. A zero downtime experience adds reliability to your business’s image, netting new customers and securing old ones.
Do I Want Team Autonomy?
Interacting with multiple teams during development distracts workers from the bigger picture. With microservices, members can work on projects without interference. A team with autonomy over a microservice can achieve a much higher quality of service and tighter deadlines.
Do I Need to Isolate Data?
Microservices allow you to partition data and grant access to only the services that need it, ensuring privacy and confidentiality of information.
Do I Want to Enable Remote Work?
You can access the REST endpoints to a microservice remotely with the proper authorization. Also, because microservices are platform agnostic, any device can do it.
When Are Microservices Not Right for Me?
Microservices may not be the best fit if you do not have a good reason to use them. For example, it might not be the best course of action if a service has to make multiple API calls to other services just to function.
Microservices are also not suitable for non-growth industries. For example, if the software you’re developing isn’t going to be accessed online but is customer-installed on a local operating system, then a monolith architecture is perfect for you. Suppose you attempt to bundle your product as a microservice for a local install. In that case, it can become complicated for the average customer, who probably isn’t interested in obtaining the required skills to maintain it. It’s a good idea to wait until you can deploy a cloud solution of the product, if applicable.
Frequent changes to the models and webpage aggregators indicate an unclear grasp of the domain model of microservice you intend to build and deploy. Incorrect identification of service boundaries results in cross-service changes, which can be very expensive to fix. Also, each service is a hosted continuous integration solution, so destructive changes can lead to high costs and ownership. Namely, startups might find a monolith to be the better choice—as it’s much easier to deploy a fully-fledged codebase as a microservice than at the beginning.
Microservices help us to deliver software in an agile and scalable way, providing reusable code in a modular, decentralized, and platform agnostic architecture. However, thanks to its complexity, success at the enterprise level requires more than new architecture patterns.
Having to grapple with and configure microservices connectivity across distributed networks, mitigate latency, and ensure security, might keep you from doing the things that matter in your business.
That’s why Kalix Serverless PaaS comes highly recommended. It reduces microservice complexity with an application abstraction layer that pulls in databases, message brokers, memory caches, and service meshes, creating a unified programming model and developer experience for the cloud and edge.
Kalix removes the barrier to the world of microservices and, through clever abstraction, delivers a platform that allows any developer to build powerful cloud-native applications. With Kalix, you don’t need to worry about the underlying infrastructure. Everything is taken care of for you—so you can enjoy a clean, scalable, serverless environment without the hassle or cost of building one.
Get started with Kalix to build cloud-native applications quickly and predictably.