We went to skills matter's µCon this year with two main objectives in mind. First of all, we wanted to benchmark how far along we were in our journey towards Microservices and DevOps, and attempt to validate what we had done in the last year. Then, as we are splitting our large monolithic application into separate bounded contexts, our second objective was to get some pointers from people who had experienced this already.

Microservices are not a newly discovered silver bullet

Microservices were one of our top objectives for the past year, with a strong focus towards Continuous Delivery and a better collaboration with our Ops. Great news is most talks in µCon were resonating with what we’ve been doing.

As we found out ourselves, Microservices and DevOps are much more about the culture and the people than the specifics in the code or the tools. Communication is key, breaking down the silos of Development, UX, Product Management or Ops, allowing everybody to work towards the same goal rather than having hand-overs between each team. In short, a Microservices architecture cannot be driven only by developers that want to do the next cool thing.

Most of the talks were aimed at general guidelines on how to build a successful microservices architecture, without focusing too much on strict rules and especially not falling into the trap of using opinionated frameworks. A lot of speakers loved to make a point on how pointless it is to ask "How many lines should a Microservices be?"... to be honest I doubt anybody really thinks it’s that important, but this highlights that there is no magic recipe that should be followed to the letter.

All in all, Microservices are not a new thing, but rather another take into decoupled systems with well defined boundaries. When implemented correctly, they provide a structure to allow independent deployments, independent scaling and most importantly independent failures. Greg Young focused most of his keynote on this and especially optimising the architecture towards "re-writability".

Existing systems: how to break down the monolith

The development of the Newsweaver application started almost 10 years ago and the result is a very successful product. Unfortunately, in the last few years we have seen our development velocity decreasing more and more. This is not saying that as developers we are doing less but that from a product point of view, it is becoming harder and harder to deliver stories, as time spent maintaining the system is increasing.

It seems like we’re definitely not on our own in this position. A lot of companies have become successful with a Monolith but decide to move towards a more decoupled architecture to face the challenges of large applications and large development teams. As I said above, we have had a lot of focus toward Microservices and Continuous Delivery in the last year, when building the new Newsweaver Analytics product. All this was done with the intention of bringing this architecture and its advantages to the existing Newsweaver product.

The talk From monolith to microservice from Ian Cooper was precisely what I was expecting to see at µCon and there was a lot to take away from it.

First of all, when splitting a Monolith one of the first things to understand is where the different bounded contexts lie. Luckily we have been quite passionate about Domain-Driven Design in the last few years, so this resonated really well with the way we are seeing our existing application. Even though right now all these contexts are still very tangled inside the Monolith, there is a growing understanding for Developers and Product Management of what these contexts are. We now have a dedicated team working on the monolith code-base and their focus is to split out these bounded contexts and define explicit interfaces between them.

The next thing when moving to microservices is to concentrate on what brings value to the product. In other words, don’t reproduce all the features in a different architecture, but focus on the core features instead. This is something hard to do when a product provides a lot of different features and removing features can be seen as a step back. Analysing feature usage can help get an understanding of what areas can be quickly retired - and having numbers to back these kinds of decisions is essential. If some parity features (i.e. features that are required but that don’t bring a competitive advantage) really have to stay, this might mean the Monolith can live on, while we focus our attention on extracting (or rebuilding) the critical high-value features.

So how are we doing?

After the first few talks of µCon, I was thinking to myself "Hmmm I’m not really learning anything, we already do a lot of this". This was actually nothing to be disappointed about, but rather pretty good news for us: we seem to be doing things right! (unless it’s just the Microservices hivemind?)

After the two days however, a few areas emerged where we were lacking. Even though we have improved our Monitoring a lot in the last few weeks (especially with Prometheus following Velocity), our general tooling still needs attention around things like alerting, circuit breakers, synthetic monitoring, etc.

The one thing I was expecting to hear more about at µCon was event and message based communication between services. While these were mentioned in a few talks, nobody really dived into it. This is an area we’re going to explore ourselves very shortly, to replace some of our heavy use of synchronous REST APIs by more asynchronous messaging and event sourcing.

Overall, µCon was an interesting two days, with more validation that we seem to be doing the right thing. I definitely count on attending again next year and who knows, maybe speaking this time about our journey in breaking our own Monolith?

What talks should I watch?

All the µCon talks are available on the skills matter website, you only need to register (for free) to have access to the videos.

I already mentioned Greg Young’s keynote and Ian Cooper’s talk on moving from Monolith to Microservices, but there are two other really good talks I would recommend watching.

Daniel Bryant’s talk, The Business Behind Microservices: Organisational, Architectural and Operational Challenges, gives a great overview of real experiences from implementing Microservices from scratch or Breaking monoliths, and what are the key elements to make these experiences successful.

Tomasz Szymanski & Marcin Grzejszczak pulled off a full live-demo style talk, which is always very tricky. In Microservices - enough with theory, let's do some coding, they go through an (almost) real-life example from coding microservices to deploying them and monitoring them in production.