The first mentions of microservices being a solution for eCommerce came around 2013. Well, you could say AWS was just launched in 2006 with just storage services (S3), and then computing-as-a-service came up around 2008 (EC2). However, to see the first wide-scale case studies, I think I waited a few more years.
I wrote a post on the hidden costs of microservices, that are actually, very often a problem, recently. From this blog post, you learned that, for many endeavours, it’s actually better to start slow. Start with handy, monolithic, yet, easy and fast to change architecture, and then upscale it based on the size of your team.
Are microservices the right fit for your organization?
When I asked Jan Hegewald, Chief Engineering Officer of Zalando, about their team size, he told me they have 200 agile teams. 200. That’s around a thousand people. I guess that, at this scale, maintaining one single monolith is a nightmare far worse than dealing with the complexity of microservices.
“One reason why you would like to have a microservice architecture is because it covers the components and it allows teams to work independently. [..] You can work on features in parallel that you’re not able to work on in parallel if you are in a monolith. So, that’s kind of the development scaling.”
Then, Jan pointed out the performance side of the equation. The application performance becomes much easier when the app is granulary divided into smaller applications.
“If you’re running monolithic software, you can typically only scale the whole, right? So, what if you have a backlog in, let’s say, checkout, to make up an example?
“You have to scale the whole application and all the underlying hardware it’s running on. If it’s on premise at these times, in order to scale, is just one part. This gets much easier, of course, in the microservice architecture because you can scale the parts, hopefully, independently”
Remember one number: 200. Teams, not people. Independent teams. Then, check how many people work on your project :-)
Actually, the question of whether microservices fit is more about the team structure than the number of team members.
When I spoke with Kelly Goetsch, Chief Product Officer of commercetools, about the historical motivations of implementing this architecture, he gave me a pretty realistic case. Kelly encountered this case many times back in the day at Oracle and it led him to seriously investigate microservices.
“I’ve spent a lot of time in really big companies like Walmart and Oracle, and these are each 100,000 person plus companies.
It was remarkable just how layered the organizations were. [..] Back in the day, if you wanted to set up a database, you had to have a team of very highly skilled DBAs to do that. Then, you would build a DBA group, and they would own the database, and they didn’t want pesky developers like me touching their pretty database.
[..] You know, if I was at a bigger company and I wanted to get a column added to a database table, that was a really easy thing for me to do personally. If I had access to the database, that’s a five-second change. But in a big enterprise, you have to go through a whole change request process. You have to fill out a whole bunch of paperwork.
[..] Then they take the request, they implement it in a development environment, then they give you access to the environment, and then, of course, you know your access never actually works. Then you have to verify it, and they have some system that they use to manage their work where you have to mark it as done in the workflow. Then they promote it to QA, and then they promote it to production.
That’s why you end up having all of these project managers. Because all you’re doing is coordinating the work across horizontal teams.”
When we dig a little deeper trying to define the optimal team structure for the microservices team, it becomes clear. The key for success is to define the boundaries between the teams they can work with and, most important, deploy the software independently.
The common pitfall of tech speaking a different language than the business
When I published the first edition of “Microservices book for eCommerce,” I had an interesting discussion with Alexander Graf of Spryker, who ended up publishing his blogpost, “Microservices and unicycling,” as the appendix. I was very optimistic about this architecture and Alex was, well, more pragmatic :)
Later on, I asked about it his co-founder, Boris Lokshin.
“Business users [..] do not think in modules. [..] I did not want to deal with the complexity of managing dependencies with contracts, etc. between them. They think in categories of the capabilities. So, let’s think about when they come to us. They are like, ‘Boris, I need your PIM’ or ‘I don’t need your PIM because I have my own. I will use your CMS. I don’t want to use the CMS. I want to use your search. I don’t want to use the search boards.’ We call this capability, and Gartner refers to it as, packaged business capabilities (PBC).”
I can relate to this point of view. Too often, I’ve seen the conflicts between technology and the business just struggling to communicate in the same language. I guess that Spryker’s PBC-based approach and, in general, the composable commerce approach could be a good compromise.
Keep the buy vs. build ratio at reasonable levels
Composable commerce and the PBC approach allow you to decide which fight you’re going to fight. The conventional wisdom is to build the parts of the system that make a difference to the users and forget all the rest. You’re still keeping up with the microservices architecture paradigm, yet you don’t have the burden of maintenance on your shoulders.
When we discussed the things they’ve customized at Highsnobiety, it was mostly the frontend. On top of that, they’ve added some custom tax services and order management services that are built like satellite applications.
The common pitfall of too granular microservices that don’t fit the team structure
Another problem I’ve had a chance discussing with Philipp Triebel was the “added complexity.” For me, it’s like you’re adding another layer of abstraction without the clear need for it. It’s like dividing the project into smaller services that are managed, in bulk, by a smaller number of teams. This structure can quickly lead to an overall burden for the team members with devops, maintenance, and service duties but virtually no benefits attached.
The common pitfall of difficulties with horizontally integrated features
Philip said something that Jan also confirmed. When you’re adding a horizontally-integrated feature that needs multiple teams to deploy their changes in sync, microservices architecture isn’t making this process easier. However, sometimes, there’s no other choice. It’s more like syncing the different product teams over Github or any other community of projects. Jan also mentioned the feature-toggles they’re using to get the releases in sync.
Summary
These two topics are highly correlated. Your architecture can actually be pretty granular as long as you wisely choose which services you need to maintain on your own vs. just buying on the market. Having everything on your own can easily become overkill. If you can’t buy enterprise grade software like Spryker, commercetools, and other PBCs, and, for example, just relyon open source solutions, it could be way easier to just start with the monolith.
I’ve put some notes on the PBC-based approach in the most recent Divante ebook.
I’m super curious about your feedback. What were the biggest challenges you and your team faced implementing microservices architecture?
Published March 9, 2021
