If you’re building a new enterprise web or mobile solution, one of the first things you’ll start with architecting its back-end.
Earlier, given the requirements to implement the support of third-party services via API and various clients, developers were sticking to the monolithic architecture pattern. Not only was it the most obvious way to implement applications, but also helped utilize fewer hardware resources more wisely.
Not so long ago hardware and software technologies allowed developers to involve more resources and run the app in a few simultaneous processes and services instead of a single one. Eventually, designing software as suites of independently deployable services was called the microservice architecture pattern and brought many significant advantages for engineers. Here’re the top three:
1. If you separate different components of an application into microservices, they can be developed simultaneously and thus speed up the delivery process.
2. Since components are usually spread across many servers, they’re easier to maintain and make the app more reliable and easier to scale in the long term.
3. Unlike the classic approach of “monolith” applications, the microservice architecture makes it much easier for newbie developers to join the project. With monolith apps, the longer they exist, the harder it gets for newcomers to learn them.
Note, however, that following microservices pattern is not a saviour approach that you can implement in the same manner in any app. In most projects, we at K&C also combine it with CQRS, Event sourcing and DDD patterns when designing the architecture of a new enterprise web application.
While microservice architecture brings many benefits and cost advantages, one of the most important decisions to make is to decide how far you should go with componentization of your application. You’ll have many arguments to consider, for instance:
+ The more components there in the product, the easier it is to adjust them if you’re expecting significant changes of requirements or entering a highly volatile market.
+ Updating and reviewing the implemented functionality gets easier due to the architecture’s clarity.
– However, maintaining the entire project usually becomes more challenging over time.
– More components also mean an increased amount of work for DevOps engineers expected to place them on separate servers and keep the whole infrastructure balanced.
In our practice, we had a case where the app was required to be split into dozens of separate components. It certainly showed higher performance indicators, but extremely often developers were handling problems and bugs caused due to improper microservice interaction.
Obviously, they could implement the next expected features instead of fixing such malfunctions only if the product’s microservice architecture was simpler.
So over-splitting functionality into too many services will cause additional costs for maintenance, support, and updates. Also, the team involved in such a project will require a wide variety of specific skills to be able to work on it effectively.
Here at K&C we have eventually come up with the next approach of implementing a microservice architecture.
1. Once the business logic of the future product has been defined, it’s better to start with less services to save time and efforts.
2. If there are any functional parts that turn out to be critical in terms of performance, they may be further extracted into separate processes.
3. Prepare proof-of-concept of the architecture you are going to implement (or at least most important parts of it) and see what kind of corner cases you might have.
4. Use well-known libraries and frameworks to minimize the costs of updating snapshot versions and dealing with bugs.
5. Cover your code with tests and implement integration tests for API checks.
6. Build and use a well-organized continuous integration pipeline with “one-button” deploy and release.
7. Consider using Docker and Kubernetes to orchestrate services.
While such an approach may sound pretty straightforward, our experience shows this is the most cost- and time-efficient development strategy for most enterprise products.
Most of our enterprise clients with high-performing applications prefer to stick to microservices, as they see the following benefits in this architecture pattern (when it’s followed as per our approach):
— High reliability. Since failure in one service does not affect other services, you can be sure the whole app won’t go down just because of a small bug in the code – and it will work 24/7.
— Fast scalability. Services providing critical functionality can be easily scaled to more servers (it can even be done on the fly), while with monolith apps you will be forced to invest time and resources into scaling the entire solution at once.
— Rapid workflow. Development can be done in parallel by different developers or teams which allows for adding new people quickly.
— Advanced infrastructure. While microservice architecture will require DevOps engineers in your development team, in the end it makes deployment easier and more reliable, especially due to using new technologies like Docker.
However, in the end, everything depends on the competence of your development team. Even the most professional developers can make poor decisions if they have no previous experience in following the microservice architecture pattern.
And if you’re looking for a team to help you develop or update your web project, K&C’s experts are always ready to help.