Monoliths vs micro-services, here we go again

The micro-services vs monoliths battle is heating up. The latest munition is Amazon Prime Video article Scaling up the Prime Video audio/video monitoring service and reducing costs by 90%.

At Adobe Experience Manager Cloud Service we are running the whole range from tiny micro-services to big Java monoliths. So I’ll try to give you my personal balanced view on the topic.

Any reasonably sized product with a bit of history is going to have a mix of micro-services and monoliths. Micro-services are not about the code, but the organization. This is the most valuable selling point. You cannot have velocity when multiple teams and lots of people making decisions and synchronizing multiple codebases. So to move fast you need some micro-services (for some definition of “micro”).

On one hand we have monoliths that are easier to understand or follow as everything is in the same place, contributed to by multiple teams. They require synchronization and locking around code, releases, tests, etc as multiple teams need to be involved. As time passes these monoliths can grow increasing the synchronization issues. But they are fast and efficient as all the calls between modules happen in-process and the overhead is minimal as much functionality is put together.

On the other hand we have micro-services that are harder to grasp as there are calls between multiple of them that are typically spread out across multiple git repos. The spreading of compute causes more inefficiencies, network latencies, more overhead as common functionality is duplicated in each micro-service, etc. But the responsibility is clearly delimited through APIs and interfaces that makes it easier to understand who is responsible and identify where problems are.

There is a lot of talk about teams owning one service, but I don’t think this is realistic. As time goes by services are developed and then move into more of a maintenance role that requires less engineering time and the team moves own to create other services that provide value. So any team will own multiple services, as (if) functionality grows.

For our teams splitting the monolith brings several benefits that steam from two: full ownership and faster iterations

  • the service is owned by a team
  • independent testing and release cycles mean faster time to market
  • pick the right tool/language for the job (or the prefered one by the team, not necessarily the best ūüėČ )

Some problems I have seen:

  • knowledge is limited to the owner team, there is no motivation for other teams to understand a service
  • duplication of efforts, multiple teams doing the same things (release management, logging, monitoring, etc). This is where Platform teams and Developer eXperience are supposed to jump in to make things easier
  • duplication of infrastructure and tooling around it. For example each micro-service should have their own image registry, databases, etc
  • interactions between services are in a bit of a limbo

Jenkins World 2016

Jenkins World will take place again this year (September 13-15) in Santa Clara, CA, and I will be speaking again about my experience with Jenkins and Docker in my session Scaling Jenkins with Docker: Swarm, Kubernetes or Mesos?

To register, go to https://www.jenkinsworld.com and enter in code JWCSANCHEZ for a 20% discount.

This year in Jenkins World:

  • 50+ sessions from organizations such as: Electronic Arts, FINRA, GerritForge, Google, NPR, Riot Games, Shutterfly, Splunk and Verizon.
  • Keynotes from Kohsuke Kawaguchi, Sacha Labourey and Gary Gruver.
  • Free Jenkins and CloudBees Jenkins Platform certification exams.
  • Networking with the LARGEST gathering of Jenkins users in the world.

 

 

Next Events: DevOpsPro Vilnius, MesosCon, Boulder JAM & Docker meetups, Open DevOps Milan

I’ll be traveling in the following weeks, speaking at

DevOpsPro in Vilnius, Lithuania: From Monolith to Docker Distributed Applications (May 26th)

MesosCon North America in Denver, CO: CI and CD at Scale: Scaling Jenkins with Docker and Apache Mesos (June 1st)

Jenkins Area Meetup and Docker Boulder meetup in Boulder, CO: CI and CD at Scale: Scaling Jenkins with Docker and Apache Mesos (June 2nd)

Open DevOps in Milan, Italy: Continuous Delivery and the DevOps Way (June 22nd)

If you are around just ping me!

Last and next months events

It’s been a while…

I’ve been neglecting the blog, mostly because I was writing already a lot¬†for InfoQ and joined CloudBees in April,to work on scaling the Jenkins platform with a product called “Tiger” that will be released soon (using Docker, Mesos, Marathon,… a LOT), I really need to write something¬†about it.

Plus, a lot of conference traveling and some speaking:

All the conference coverage is at my Lanyrd page

What’s next?