Macroservices vs. Microservices vs. Serverless: the story of a modern solution architect

Mick Roper
Mar 1, 2019 · 8 min read
Image for post
Image for post

3 words. That's all they are, but they pretty much sum up the world of modern software development. It wasn’t very long ago that Service Oriented Architecture (SOA) was an upstart architectural pattern threatening to shake the established foundations of software development. Then, practically as soon as it’s advantages became widely understood, the services being designed were getting smaller. With every iteration we moved to a world where hardware was less important (since the workload was less intensive), until we came up with a paradigm where the hardware can be practically ignored! Welcome to the world of serverless.

It’s great to see the number of options we now have to create our solutions, but it does introduce a problem that is fairly new in the software development world: how should you design and develop your solution. I don’t want to try and explain the technical virtues of each patten, smarter people than me have already done this. I would however like to explain why I would choose one architecture over another.

I hope you’ll come with me on a little trip through my brain (excuse the mess) to see how I make the tradeoffs — because at the end of the day that’s what these 3 options are — that lead me to choosing a design pattern, how I avoid the pitfalls and try to build for the future without losing sight of the now.

Your choice of design pattern will (almost) never be because of a functional concern. In most cases your user just doesn’t care! Whether building a video streaming service, a trading platform or an eCommerce solution, your user wants a consistently good experience. They want responsiveness, immersion and ease of use. Striking that balance is an incredibly tricky thing to do, and while a poor choice may hurt your ability to deliver that balance a good choice will not implicitly deliver it. This is an unwelcome paradox of systems design. The decisions you toil over may have minimal impact on a positive functional experience, but the wrong choice can still kill your project stone-dead through non-functional problem.

So, lets role play this. You be you, and I’ll be me (not the most imaginative role playing, but bear with me). You want me to design a system, and you want me to take you along as I move towards a design. first is the 10,000 foot view: I find it essential to focus on the following points:

  • Development velocity: the product needs to get to market as quickly as possible without sacrificing quality. Your users or sponsors may not care about the underlying architecture but they will absolutely care about the speed of initial delivery, speed of subsequent change and the overall experience. Rapid delivery results in faster ROI. Businesses (usually) love this. Good experience pleases users, and keeps them with you.

Based on these points I can’t honestly tell you when to use one architecture over another. As you can see, the choice is a tradeoff between the business, the team, and the users. These 3 groups each have their own hopes and fears. If they align closely then the choice is made easier. A team that is happy running N-Tier applications on distinct hardware, combined with a business that plans its projects 12 months in advance will see little benefit from microservices, but would still feel the pain that microservices bring with them. This team may use some serverless functions for the areas of the project where big hardware would be overkill (usually event driven components such as scheduled jobs) but otherwise their desires align best with macroservices.

So as an architect, what should you do? Always aim for the path of least resistance, and forge that path towards the objectives of the business culture. For example, if the business exists in a domain where stability is paramount and projects are closely controlled then look towards macroservices. They are not easy to change and deployment can be tricky (remembering to design for flexibility will help to manage this) but they bring stability and predictability with them. These systems are often so stable that engineers who have worked with them for a while may even be able to preempt failures under certain situations. This is still an example of stability in macroservice architecture. It’s unlikely to throw you a curveball and workarounds become ‘business as usual’.

On the other hand, your business may exist in a domain where disruption is common place. Web 2.0 startups are a great example where a wily disruptor can shake the established players within the space, and they can do it quickly. This fosters a culture of ‘disrupt or be disrupted’. Microservice architecture sprung up from this need to pivot a business and its application stack in a different direction quickly. This ability to change direction is paid for by reduced maintainability. Microservices are hard to look after! The best microservices are self configuring, self healing, self discovering automatons but they still need to be modified by an engineer when the business changes, and that change must be done in a way that does not cause cascading failure.

DevOps is the cultural response to this ‘change quickly’ business model and the paradox that a business may need to pivot quickly but people do not embrace change easily. DevOps espouses high visibility of parts combined with low communications overhead within the team to ensure that changes are understood early, implemented quickly and maintained by the creator. Without this culture a microservices architecture is likely to be difficult to maintain and may even become a major source of friction between the business and team, and when that happens you can practically guarantee it will end up hurting the user experience.

So what about serverless? This is a tricky one and I can only give you my opinion. I very much like serverless architecture. The idea of palming off most/all maintenance of your components to the provider is like a dream come true! No maintenance overheads! Huzzah!

Unfortunately it’s not so clear cut. You still have to maintain the API to the serverless provider, the runtime versions and all of your dependencies. Traditionally these things change more frequently than the underlying infrastructure would, so you need to ask yourself a question: have you truly removed your biggest bottleneck?

Some people decry vender lock-in as a reason not to use serverless but I would offer a different opinion. Most commonly used technologies start off as proprietary and move into the open as time progresses. Things like the Serverless Foundation are pushing to make entry points more standard compliant, and where they can’t then tooling is being developed to minimise the overhead. I would argue that before you start using serverless functions you have already settled on a cloud provider, lock-in has already happened. Working against becomes another source of friction.

Once your past the entry point of your serverless application you’re getting into your application’ dependencies. Chances are that if you’re building on AWS Lambda then you are also using DynamoDB, Elasticache or S3. The choice to use AWS components inside your app has nothing to do with Serverless. The offerings of cloud providers compliment each other, trying to abstract them away incase the business pivots their entire model to another supplier is extremely superstitious and highly unlikely to happen without you hearing about it months in advance. Take the path of least resistance!

That being said, I am divided on whether a full application stack could be built on top of serverless technology. While practically every solution you design can be pivoted (with a little ingenuity) to an event-driven architecture there are some major limitations inherent to serverless frameworks:

  • Timeboxing: Serverless functions run in strict timeboxes. Run out of execution time and progress is lost. You have a little control over this, but delivering a long-running workload as a serverless function may prove unstable.

These 3 architectures are prevalent in software engineering right now, but it is worth adding that just 15 years ago the fundamental idea behind microservices was an anti pattern (‘extreme SOA’ was frowned upon as excessive fragmentation of the problem domain) and serverless wasn’t anywhere even on the horizon.

The speed of technology is only increasing — today’s fad is tomorrow’s de facto choice. As an architect its important to rise above the technical choices you will be asked to make and instead try to see the big picture. Avoid closing a door by choosing an architecture that is hard to walk away from or difficult to maintain in the long term.

Make every effort to understand the people — the business, the engineers and the users. People want software, people build it and people use it. Without people you don’t have a role so keeping them central in your mind is core to your success or failure. It is incredibly difficult to make all 3 groups truly happy but it is possible to strike a good balance of contentedness between them.

I’d like to leave you with one final piece of advice. Don’t burn bridges, be they technical or political. Without the business behind you you won’t know where the value is, without the team you won’t deliver any value and without the users there is no value to be delivered.

Don’t rule out a choice because you don’t like it on non-technical grounds or simply don’t understand it. Tech suffers from entropy more than many fields, todays goto tech is tomorrow’s roadkill.

In the words of Uncle Bob:

Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity

‘Easy’ is loaded with context, but if you can deliver it then you will succeed.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store