JAX DevOps Blog

JAX DevOps, 14-17 May 2019
The Conference for Continuous Delivery, Microservices, Docker & Clouds
19
Feb

Microservices? yes! but no spaghetti please!

Microservices, yes! but please no sphagetti. Pay attention to your services calls:

Pay attention to your services: Shutterstock

In this interview, Peter Eijgermans talks about the differences between a monolith and microservices, when to use each approach and what tools to use when managing microservices. Watch out of adding moe complexity than needed when hopping on the microservices board. JAX DevOps session preview.

JAXenter: What are the differences that people might not be familiar with between a monolith and microservices?

Peter Eijgermans: Microservices have a much more complex ecosystem than monolithic applications, sometimes the complexity of the system as a whole is much larger than a monolithic application. Think, for example, of container management, distributed tooling such as rancher, mesos, etc … Also testing and deployments to production are significantly more complex. The organization must be geared to making microservices. In other words, a monolith is often much simpler.
– Microservices communicate (preferably) asynchronously via a message bus instead of synchronous calls in a monolith. That makes debugging etc, much more complex.
– Monitoring is essential in a microservices architecture (which is often forgotten or not well set up).

People are often unaware that microservices really need to be independent.
For example, you often see that all kinds of services are being made but that 1 database is shared. Another problem is that people program what they were used to doing in a monolith, making the chain of synchronous calls between services (over the network !!!) much too long. No attention is paid to “spaghetti structure” that can arise from all kinds of services that use each other and services are tightly coupled

JAXenter: What are the advantages and disadvantages for each approach?

Peter Eijgermans: Compared to de monolithic model, a microservice has the following pros and cons:

  • When you use the microservices architecture, you will have increased decoupling and separation of concerns. Since you are literally splitting up your application in separate services. A Service is a modular component only accessible via their own contract, and hence less prone to turn into a big ball of mud.
  • Code in a microservice is restricted to one function of the business and is thus easier to understand. IDEs can load the small code base very easily and keep the developers productive. It doesn’t matter what language, framework or database is used as long as it is the best suited for the job.
  • You will have more agility to roll out new versions of a service due to shorter build, test and deploy cycles. This also means little downtime during roll out.
    But on the other hand, deploying multiple services is also more complex (many more moving parts that need to be configured, deployed, scaled, and monitored).
  • Since the different services are small and deployed seperately, it’s obvious easier to scale them, with the advantage that you can scale specific services of your application.

But there are also a lot of drawbacks:

  • Testing a microservices application is also much more complex. Example: a test class for a service would need to launch that service and any services that it depends upon (or at least configure stubs for those services). And Implementing changes that span multiple services or updating multiple databases owned by different services is also very difficult.
  • Finally, a service’s API invariably changes over time: In a monolithic application, it is usually straightforward to change the API and update all the callers. In a microservices-based application it is a lot more difficult, even if all of the consumers of your API are other services in the same application. You usually cannot force all clients to upgrade in lockstep with the service. Also, you will probably incrementally deploy new versions of a service such that both old and new versions of a service will be running simultaneously.

JAXenter: What is the correct way to use microservices?

Peter Eijgermans: The question is: for what type of systems do you have to use microservices and when not?

  • Competing websites that need to be adapted quickly to changes in the market are suitable (webshops, banks, newspapers, search engines, etc).
  • Application in which a lot of data is processed.

JAXenter: What kind of tools do you use when managing microservices?

Peter Eijgermans:
Resilience:
Netflix OSS
tools, Hystrix, Ribbon, etc…
Platform:
Kubernetes,
Zookeeper,
Mesos, Marathon, Rancher, Puppet, Chef, Ansible, OpenStack, Netflix
Eureka …
Delivery:
GITLab, Bamboo, TeamCity, GoCD, Jenkins, Docker, rkt (Rocket), …
Logging.Metrics:
Prometheus, GrayLog, LogStash, Kibana, Grafana, ElasticSearch, ……
Messaging:
Kafka, RabbitMQ, …
(Distributed)
Databases:
MongoDb,
CouchDb, Cassandra, MySQL, Postgress

JAXenter: What do most people or businesses get wrong about microservices?

Peter Eijgermans: People are often unaware that microservices really need to be independent.
For example, you often see that all kinds of services are being made but that 1 database is shared. Another problem is that people program what they were used to doing in a monolith, making the chain of synchronous calls between services (over the network !!!) much too long. Neither is attention paid to spagetti structure that can arise from all kinds of services that use each other and services are tightly coupled. The infrastructure for monitoring, automatic testing and deployments is often not fully set up but for 3/4 or 1/2, so the benefits of micro services can not be used, but the burden.

JAXenter: What will participants be able to take away from your talk?

Peter Eijgermans: My talk is focusing on the following topics:
– Microservice Design Patterns
– Strategies to convert a monolith to microservices
– Answering the question: which is better, microservices or monolith?

Thank you very much!

Check out JAX DevOps sessions by Peter Eijgermans

Behind the Tracks

BUSINESS & COMPANY CULTURE
the process of becoming fully agile
CLOUD PLATFORMS
Cloud-based & native apps
DOCKER & KUBERNETES
Docker, Kubernetes, Mesos & Co
CONTINUOUS DELIVERY
Build, test and deploy agile
MICROSERVICES
Maximize development productivity
Business & Company Culture

Business & Company Culture

Cloud Platforms

Cloud Platforms

Docker & Kubernetes

Docker & Kubernetes

Continuous Delivery

Continuous Delivery

Microservices

Microservices

Monitoring & Diagnostics

Monitoring & Diagnostics