Our partner ENGINIETY talked with Dave Morris, Delivery Director at REWE Group & Head of Engineering at REWE Digital, to get further insights about API-first, Cloud, and Headless in the context of microservice architecture.
First, it should be noted that both microservices and monolithic approach are perfectly valid architectures with advantages and disadvantages.
Apart from a change in the mindset, the essential difference for me is a shift in complexity from development to operations. Microservices are easier to develop and change, but harder to deploy and manage. Hence the greater tooling, efficiency and consistency you have in testing, deployment, rollbacks, logging and other cross cutting concerns, the better and easier it is. And also, to be honest, I think that whilst concerns about managing Microservices are valid, they are also a little ‘over-emphasised’.
The move towards Microservices is actually driven by our changing business environments. We face constant disruptions and emerging innovations on the market. The new technology provides new opportunities. Microservices allow you to make constant small changes with confidence and adapt and re-adapt your business model. These changes could refer to functionality or scalability or both of them. I can independently scale any of our services to meet higher business volumes, without having to ’put another server in’.
Microservices do not mean “the Cloud”. The Cloud is just another deployment option. It is true to say that there is a correlation between the advantages of the Cloud and Microservices. Therefore, there is a correlation, but not causation. However, you can also realise a Microservices deployment with the on-prem model and there are plenty of good tools to do it in both environments.
Once you have made the decision to go with Microservices, you can ask independently: ’Are we, as a business, going to the Cloud or not?’. The big thing here is not the considerations themselves (they are unique to every business and mostly dependent on costs, security and data concerns). The important thing is to make the decision early and stick to it. It subtly changes the Development, deployment and tooling you need, and you need to know that early on in your development of the services.
I think the API-first approach is something we are still trying to get to grips with. It forces a discipline into your Ecosystem, which means you have to take into account the public contract of the API before you develop your Microservices. By designing your API first, you are able to discuss with the stakeholders the intent and functionality of the feature(s), before you might have coded yourself into a ‘black hole’ where no escape is possible. This interaction allows you to build user stories and mocks of the service(s) you’re building/changing and allows teams to work in parallel.
APIs have typically either been A) developed as an afterthought, and/or B) maintained in parallel with the development of other features. In truth I think we are still in the ’B)’ territory, given the pressure to respond to market changes and come up with innovations.
Yes! Microservices are self-contained universes (they are products). Typically they are owned by a team and the team work on their part of multiple initiatives (projects) in parallel. Some of them are big, some are small. These teams develop, deploy and RUN (!) their services, and therefore there is no or a very slim Application Support team who have to keep the thing going at weekends! Monoliths cannot be broken down like that, so typically the teams are organised with a project focus. These teams generally work on one project at a time, and deliver one massive change into Production where there are Support teams and Application Support teams picking up the pieces. Of course this is a cartoon description because both ways can be made to work, but you get the idea.
In the Microservices architecture it is almost a given. We can react to business peaks by spinning up more of the services we need to do the heavy lifting. In that sense, we are secure from having to ‘plan’ for peaks – we just react when we need to and are safe in the knowledge that we can.
Oh, I think it is more than just a buzzword. Like so many things, it can be overused or overapplied. Headless simply refers to a clean separation of concerns between the client side (and the uniqueness of the device) and the server side (where all the logic and data are stored). If you achieve that clean separation, there is no need for a mobile to have its own database for x or y, or the web channel to have a different perspective on what status an order is, than the customer service agent. So there is a real benefit too. The big nut to crack here is the CMS, which I do not think we have truly achieved yet.
Make decisions early on your deployment and operations environments particularly cloud, tooling, orchestration and build this out early (if not first).
Aim for consistent standards around the cross-cutting concerns, in particular of logging and monitoring.
Move to a self-organising product development organisation with higher levels of agility as the default, and not a project organisation.
Apart from that enjoy the ride!
Discover more about how the commercetools' Microservices architecture is enabling digital commerce at the speed of MACH.
This article by Katarzyna Jędrzejewska first appeared in ENGINIETY.