What are microservices? They are loosely bound, light services and protocols that can build your application. Highly specialized in nature, they tackle specific topics and handle challenges in a very agile way. Through this specialization, your application can perform better. What exactly is microservices architecture and what are the advantages of microservices?
To answer these questions, we have to break down the software development process into two main categories. If you want to create a digital product, there are two choices:
- Monolithic architecture
Both of them have advantages and disadvantages and no, microservices are not for everybody. They shouldn’t be treated as a panacea for every development challenge, but we will have a separate article on that in the near future. For now, let’s focus on the matter of why microservices are good for business.
Table of contents
- What are microservices and why they are important
- Why are microservices important?
- Why microservices? For what they are used for?
- Benefits for your digital product
- What is microservices architecture?
- Microservices architecture and the learning curve
- What are the types of microservices?
- What are microservices in AWS?
- What is microservices architecture? Ask yourself!
What are microservices and why they are important
In today’s business, the ability to respond to changing market conditions is vital. To keep up with constantly changing demands and competing products, you must adapt and change. Making pivots in your business, regarding sales, marketing, and product strategy, is everything. That also applies to the product itself, which can even demand changing an entire architecture. Or at least part of it, if that’s the case.
The modern digital project requires few things to compete on a market and most of all, satisfy their users. They need to be:
- ready for quick deployment
- easy to maintain
- easy to scale and change on demand
- available (have a small percentage of downtime)
Why microservices for your project? Because they are responsible for a small portion of what happens in your product. They are also modular in nature – which means that they are easily and independently scalable. You don’t have to change the entire code to allow more people to use the application. To do this, simply adjust microservices and their scope. Also, corresponding microservices, so that they can work better together.
How does it work in practice?
The characteristics of a microservice are not complicated. Each microservice:
- has its own data model and manages its own data without 3rd party support (from another microservice, additional code, etc.)
- encompasses a single piece of business functionality. It’s called a domain-driven design (DDD) or bounded context. In other words, if something is good for everything, it’s good for nothing. That’s why each microservice is responsible for a very specific task and nothing more.
- internal operations within a microservice are available to external programs only through API.
Why are microservices important?
Because they deliver on a promise of quick deployment and specialized agenda.
- They maximize deployment velocity. Each application runs its own containerized environment, so they can be moved anywhere else without messing up the environment they were previously in. That’s a great benefit for integrity and future projects. Not to mention the current’s one performance.
- They empower developers. Each component of the application can function in its own container. That’s why it can be individually updated and managed. Fixed, enhanced, etc. If there is a bug, a developer doesn’t have to go through a bigger portion of the code. He or she can simply use a scalpel and apply a fix accordingly. Updates and functionality enhancements are also easier – if something is isolated, and microservices are, you can sit back and relax. Applied changes will affect only the microservice at hand.
- They can be written in different languages. When it comes to Code & Pepper, our technology stack allows us to quickly adapt and scale products. We decided to go with microservices because they allow us to be even more productive and agile. Not to mention write microservices using respectable languages, suited for particular needs. You don’t use a SpaceX rocket to travel to a local supermarket. A small city car will do, right?
- They allow significant cost reduction. In a monolithic architecture, every change, especially later in the project, is complicated and potentially expensive. Every part of the application interacts with other parts; change in one place affects other parts of the application. It’s a ripple effect – the more significant the change, the more work you need to implement it. It’s different with microservices – you work only on what needs to be done. You don’t have to estimate costs of side effects (additional quality assurance, bug fixing, post-launch support, etc.)
Why microservices? For what they are used for?
There are many potential applications, but here are few most important ones:
- processing data
- recommendation based on historically similar choices
- delivery of media content
- processing and ordering payments
- website or application migration (from monolithic to cloud, to web services model)
- data offloading
- configuration management
… and some more. A single microservice can be a very versatile tool. Depending on your current application’s needs, it can give you various benefits.
Benefits for your digital product
Aside from the features above, there are many advantages of building digital products with microservices.
- Continuous deployment / continuous integration. These are big advantages in development. Both are key concepts in DevOps and generally, an Agile approach. Because teams can quickly develop, test, and implement necessary changes in the code independently in each service, it leads to shorter time-to-market and troubleshooting turnaround times.
- Reduced application downtime. When one element goes down, everything does. This golden Murphy rule has no say here. Because every microservice is a different organism, when it goes down, it only affects one functionality. The application as a whole can run smoothly. This is unlikely in a monolithic architecture.
- A smaller codebase enables a team to understand the code and simplify maintenance. This is pretty much self-explanatory. With self-managed microservices (oversimplification but you got the point), developers can only look at the code that generates problems, not look for a needle in a haystack. Because the problem is not regarding the whole application, it’s easier to spot it and neutralize it. Smaller areas mean less code and that leads to in-house transparency.
- Faster development of an MVP and time-to-market. With all features mentioned above, it’s easier to build scalable products and their very early versions. If you’re not entirely sure what the product should look like, don’t have a full budget right away, or want to test a concept, go for a minimum viable product. That way you won’t be burning time for more expensive options and customers will have an option to quickly have their say on the product. Their opinions matter most in the first, post-launch phase, so use them to build on that and improve the application as soon as possible.
- Outsourcing flexibility. Some managers and business owners are worried about protecting their IP. Since Poland, and as a consequence Code & Pepper, are in the European Union which protects intellectual property, we don’t experience a serious level of doubt. Regardless, some partners can have objections when it comes to end-to-end development. In this case, microservices allow flexibility – you can segment off work for the outsourcing of non-core business functions without disclosing core services.
- Native support for cloud-based solutions. Microservices has been around for years now but it’s still a fairly new concept. Just as cloud services, which complements microservices in the right way. You can drop and keep necessary data in the cloud, freeing resources for more important parts of the product. You get data and performance from the cloud – when you need it, the way you need it.
- Ability to experiment with technology. Since microservices are technically independent, you can write them in whatever you want. Even if your company has a product with legacy code and wants to add new features which demand new languages, frameworks, libraries, we can do that. Our tech stack allows a high level of agility, which complements microservices focus.
- Presence of cross-functional teams. It means that a team has all the necessary skills to turn a product backlog into a fully done increment. By organizing people and working this way, you and your software development provider can handle multiple projects without sacrificing quality in each of them. Cross-functionality is another word for efficiency.
- Less operational overhead. The less you have to think about, the more you can focus on what’s really important – building and expanding your business. Microservices don’t require exponential budgets, multiple teams for even small projects, and doubled positions. Developers and product managers can handle their own.
What is microservices architecture?
Imagine a chasm that you can’t cross because you lack a bridge. You can use a ladder but it will take some time. This is microservices architecture in a nutshell. Because we have something called “a hard crosswalk”, it’s difficult to walk over the system and mess things up in a code. Or implementing additional functionalities in post-launch support, which is equally important for everyone involved. Just imagine a well-received product that gets an update and everything suddenly goes down for hours if not a few days. Unacceptable. With microservices, it’s easier to manage everything.
Basic rules of engagement
It is and it isn’t. And least in the very beginning. You make your microservices too granular and your system becomes overly chatty. Microservices will have to constantly talk with each other to exchange information, push data, and other necessary things through. Push too many functionalities into a single service and you sabotage yourself with a serious scalability challenge. How small is “a good small”?
The answer lies in the concept of a domain-driven design. You have to model your microservices around key business domains of the system. Expose only necessary information, that way parts of the product will exchange only what is truly necessary. This is called “boundary context”.
For example: if you have an ecommerce solution, your bounded context would be information about a shopping cart, inventory in the sop, what user is using the cart, etc. Security? What for? We have a specialized microservice for that. Payment? Another part of the system, sorry. Application update? Wrong address, we have an app… sorry, a microservice for that. In essence, it’s about system architecture mimicking your team’s structure. It’s known as Conway’s Law.
OK, we have that covered, now what? Monitoring and health management. Scalability is cool but if a small, very specialized microservice catches a cold, you may not see it for quite some time. The cold, not the microservice. When an application is broken down into many cooperating and sometimes co-dependent parts, the natural outcome is more ground to cover. Advanced monitoring algorithms can help with that.
And that brings us to testing. With so many moving parts, you need a good system for quality assurance. A good testing strategy should involve coverage of every component in a product unit, component, integration, contract, and end-to-end testing will help you spot issues.
Things get a little more complicated
And they can pop up; nothing is ever perfect. There can be dependencies that form an issue but how to break dependencies of components that form a single system? Through contracts, which define how an API looks like, which data it expects and which one it returns. You can think of it as an agreement between a supplier and a consumer. They talked and agreed on what should be delivered and how but not how goods are produced or who supplied electricity to the factor that makes these products. Both parties should care about it all, right?
Naturally, at some point, you will need to modify the contract a little bit. That’s where versioning comes on stage. You can version contracts with Semantic Versioning and automate contract compatibility tests. Consequently, tools like Pact will help you manage all contracts and their versions.
Of course, questions like “what is microservices’ architecture” spawn different ones. Like, for example, “where are my product’s logs?” With monolithic application this question is easy to answer – here’s the location, have fun. With microservices, especially their multitude of instances and massive production of logs, things get a little tricky. Basically, you need two things: log consolidation and correlation.
With logs consolidation, you have access to all the logs from a single place. There are, however, different solutions to this. You can set up a global shared folder which all microservice instances write. You can have a dedicated microservice that gathers log entries to tools. For example, ELK (Elasticsearch, Logtash, and Kibana) plus Serilog. This makes logging to a common location easy to configure. Plus, it makes all the logs easier to search through.
OK, that’s covered, but what about readability? To make your life easier, you can add correlation ID to the very log entry. Correlation ID allows to track logical flow as it travels through multiple services. Just remember to pass the ID with every API request you make (HTTP header is perfect for this).
Microservices architecture and the learning curve
To squeeze the most out of microservices, you first have to understand them. There are few components to each microservice:
- the microservice itself
- service mesh
- service discovery
- API gateway
Each of them is responsible for a different aspect of functionality. Containers, for example, package services and their dependencies. They make sure that the unit is consistent throughout the entire development process. That includes testing as well. Service mesh, on the other hand, facilitates communication between microservices. All happens through a specially created, dynamic messaging layer.
Service discovery helps the system to adapt to changes in deployment. It helps microservices locate each other in a network. Finally, the API gateway creates an open line between microservices and outside clients.
This is the infrastructure for you. Sounds simple but this description is only skin-deep. There is a lot of business logic going into every aspect and a lot to learn on the developers’ part.
Studies and conclusions
There are a lot of companies using them and we will touch on that in a separate article. For now, let’s head on to the 2020’s microservices adoption study by O’Reilly.
Most adopters think they are successful after bringing this tech to the table. 10% reports a complete success, 54% of responders think the adoption went mostly successful and 92% reported at least some success. At the same time, they are surprised by the microservices’ level of maturity.
Interesting data surfaces when it comes to conclusions. 74% of responders say that success with using microservices leads to owning the software lifecycle. In other words, microservices are like New York. If you can make it there, you can make it anywhere.
It’s interesting, especially from a distance. In this 2018’s study by DZOne, 59% of respondents admitted using microservices in some capacity. 38% of them used microservices for development and production, 16% for development only, 5% for production only. Almost 60% of asked companies use microservices – which shows the architecture can be mastered. At least understood and accepted, leaving actual product development to the specialized companies that can support digital transformation.
When asked ‘Why are you using microservices?’, 69% responded that making applications easily scalable is imperative to them. 64% of companies wanted to enable faster deployments to one part of an app. That’s not surprising at all but we have to remember that there’s a learning curve when it comes to that. Many executives and developers ask “why microservices?” and are charmed with benefits but it’s not necessarily that easy.
What are the types of microservices?
That’s because many targeted options need many targeted, individualized approaches. But also, because there are types of microservices. Broadly speaking, there are two types to be exact:
- Stateless. They don’t maintain a session state between requests. Let’s show it in an example: if any of the service instances is removed, it doesn’t affect the processing logic for the service. Distributed systems prefer stateless microservices.
- Stateful. They store session information locally (in a given instance, in memory or hard drive). When two or more microservices communicate, they maintain a service request state. In the real world, stateless services are a good choice, but there are multiple use cases where you need to keep state information.
Without going into big details, these are the two main types.
What are microservices in AWS?
Amazon Web Services or AWS for short is a great choice for not only powering your digital product but also to implement microservices. In the near future, we will have a separate article on how to deploy microservices on the AWS cloud. For now, let’s stick to the basics.
AWS is widely used to implement applications powered by microservices. It can support them in the following areas:
- continuous delivery / continuous integration
Here’s a typical frontend of an application based on microservices and deployed through AWS:
What is microservices architecture? Ask yourself!
This slightly provocative subtitle serves as a reminder that the final application’s architecture is up to you and your business needs. Your response to the market’s expectations should define the final inside look of the product you’re after.
This can be complicated, so use team augmentation services to help you out.