Is this a Microservice PaaS?

A beekeeper looking at a frame of honeycomb from a hive. This blog looks at how a Microservices PaaS Design might be framed. Last week I wrote about PaaS and Microservices, asking, “Is a Microservices PaaS in our future?” Since then, I’ve had a number of URLs thrown at me along with the question, “Is this what you mean?”

Probably the closest in intent, based in the way they’re marketing themselves, are Giant Swarm. These guys are certainly putting themselves out there as “Simple Microservice Infrastructure”, and I think they’ve made some ground on implementing such a thing by including service discovery as part of their platform.

Does Docker == Microservices Paas Design?

However, my impression from their docs, as I explained in a comment on said previous blog, is that so far they’ve really only built a “Docker-based PaaS”, and are leaving most of the work of building a MSA, in terms of both choosing and configuring technologies, up to the developers of the system. To quote myself again: “in terms of setting me up with an architecture, it stops at ‘You’ve got Docker!'” (I didn’t realise it had service discovery when I wrote this.)

One of the Giant Swarm developers, Timo Derstappen, joined in the conversation. It’s obvious from his remarks that they’re planning more than just service discovery, as he says “Metrics and logging are not yet there.”

He also said, “The main thing I don’t like [about] the PaaS term is that it’s always [meant] it’s opinionated. I think it should be easy in the beginning but if the out-of-the-box solution doesn’t fit any more we don’t want to stand in the way of our users.” I agree with this sentiment, and I think it is the right way to go… ultimately. But right now, being able to choose which technologies to use is not the main problem a microservices team will have. The main problem today is that it’s SO MUCH WORK setting up a production-quality microservice environment.

What does “Platform” even mean?

What, after all, is a technology “platform”? To me it is simply this: something that does a lot of work for me, as a developer or Ops, so that I can do more of the business’ bespoke work. As opposed to IaaS, which simply provides resources for a team to use (hence removing work for the Ops team), PaaS does the same but also makes use itself of those resources in order to present a platform that removes work for the Development team (and usually more for Ops, too). In that sense, the more work it removes for the Dev team, the better a platform it is.

A Microservices PaaS Design

Timo asked me, “What are the things you would like to have from a Microservice PaaS? What would make the difference for you?” To answer this question we need only look at all the stuff that microservice development teams are doing that’s not their core business.

Here’s a list of things that I think the ideal Microservices PaaS would provide*:

Service discovery
… including client libraries, if they’re needed
… and load balancing
… and local preference for geographically-distributed systems

A database
… including backup management
… ideally on-site and off-site

A distributed, persistent, fault-tolerant message broker

Log aggregation & search

Monitoring
… of the infrastructure, and the application’s health

Metrics
… of the infrastructure, and the application’s health and business activity

Alerts

Status page

A standard user storage and authentication service
… with state of the art secure credential storage
… and the ability to support principal propagation

SIEM
… Intrusion Detection?
… Intrusion Prevention?
… DDoS protection?

Multi-zone/region deployment options (because you don’t care where your apps run, until you realise you should have cared)

All of that is stuff that a microservice PaaS could provide to take work away from Development and Ops teams to help them launch their system earlier.

Beyond the simple Microservices PaaS Design

There’s other areas as well that such a platform could also expand into, both before and after “launch”, to help support the team:

Local hermeticity (aka Dev/Prod parity) – The system is simple to deploy and run in Production, but how simple is it to get it up and running on your desktop to test it? This is something which the design of a PaaS could make either very easy or very hard (or just a lot of work, even if it’s not hard). If it’s hard, it’s going to affect the developers … every … single … day. Does the PaaS provide scripts and/or service stubs that allow easy emulation of the PaaS stack?

Continuous delivery pipeline – The system is simple to deploy and run in Production once it’s ready to be deployed, but what has to happen before that? This is something that many Dev teams (and quite a few SaaS startups) are investing a lot of time in at the moment. If it could be solved in the same offering as a microservice PaaS, that could be very compelling. At the very least, the PaaS should make itself extremely easy to integrate with other hosted CD solutions.

Elastic scaling – The application is a wild success. Can the PaaS manage that success on behalf of the team, or do they have to manage it themselves? (Alternatively: The application is still waiting for that hockey-stick growth. Does the PaaS ensure the system isn’t over-resourced and the business overcharged?)

Microservices PaaS Design: Plenty of Scope, Plenty of Shoulders to Stand On

So you can see that, taking the definition of a Platform as being something that removes work from the team using it, there is a lot of scope for platforms supporting microservices teams to provide a whole suite of functionality that will save the team masses of time.

Of course, the PaaS team doesn’t need to develop all this stuff from scratch. There are multiple options, both open source and commercial, for each of the above domains which they could leverage for the benefit of their customers. The technologies don’t even necessarily have to be baked into the platform. They could be delivered, by a vendor such as Giant Swarm, as a template that describes and configures a whole standard architecture, leaving the Dev team to simply fill in the gaps where the business logic belongs. (That everlasting dream!) Some of these requirements, though, for instance off-site backups, may not be so easily solved in a template. In fact, many of them may be better solved if the technology is “managed” rather than just being easy to spin up but then left in the control of the customer.

In the future, I think microservice teams looking for a PaaS might demand choice in which technologies are used to solve these problems, but today I think most teams would happily trade choice for an easy, quick setup with sensible defaults. Giant Swarm’s attitude of “we don’t want to stand in the way of our users” is a good one, but that is only an issue after the basic requirement of “it should be easy in the beginning” is satisfied, and I don’t believe anyone’s close to nailing that yet.

* This list comes partly from my own experience but also owes much to the knowledge sharing of Yamen Sader, Sam Newman and Zhamak Dehghani.