PaaS for microservices, part II

In my last post on the intersection between PaaS and microservices, I got a little distracted by infrastructure and scalability. By the time I wrapped it up, I wanted to get back to why I initially questioned current PaaS offerings for microservices.

Perhaps it’s because I want my PaaS to not only recognize I’ve deployed microservices, but to make running microservices easier. What’s that mean? I have a few ideas in mind.

Dependency resolution

First, it would be great if my PaaS helped identify dependencies between microservices. Yes, each and every microservice would be completely isolated and independent in a perfect world. If you happen to live in one, send me an invite. In my world, microservices can call each other (even if I would prefer them not to). Heck, the use of messaging is still an indirect dependency. Let’s say microservice A publishes messages to a topic, and microservice B subscribes to it. What happens if a new version of microservice A is deployed, and it changes the message format?

Atomic deployments

Who cares? My PaaS will prevent me from deploying this new version of microservice A by itself. It could be that due to a dependency, and I have to push new versions of multiple microservices together. Or, it could be I’m introducing features/enhancements across multiple microservices. Either way, I want my PaaS to let me add multiple microservices to a deployment task – and it needs to push new versions of all of them, or none of them.

API grouping

This one isn’t very big, but I think I would prefer to group related microservices. For example, let’s say I have separate microservices for managing accounts, rewards and billing. I might want to consider these my customer API. However, I know API is a rather overloaded term right now. I suppose I just want to create logical collections of related endpoints that may span multiple microservices.

Endpoint catalog

Seeing as I’m deploying microservices, I want my PaaS to show me all of the endpoints associated with different microservices. Okay, maybe we need a quick aside here. I’m not very strict when it comes to microservices. If I were building the backend for browsing a product catalog, it would likely include microservices with multiple endpoints. I probably wouldn’t create separate microservices for create, read, update and delete operations. And yes, integration of Swagger would be nice. And of course, I’d want my PaaS to automagically generate the docs – even if it means developers need to add a YAML file to their microservices describing the available endpoints.

Microservice toolbox

The toolbox of current PaaS offerings is often filled with databases, message queues, search engines and other data-centric components. However, part of the complexity of microservices stems from a growing ecosystem of API and workflow orchestration components. I believe a PaaS optimized for microservices should deploy an API gateway out of the box, and should automatically configure it based on the endpoint catalog described above. Then, either provide direct access to the gateway’s admin UI or indirect access to its features via the PaaS. To me, this is the type of thing a PaaS can do to help developers get started with microservices. And an API gateway is just one example. 

These are just a few of the features I’ve been thinking about as I ponder what the perfect PaaS for microservices would look like. I’m sure there are plenty more, but really, it comes down to making life easier for developers. The perfect PaaS should recognize you’re deploying microservices and step in to help.

What’s next? Maybe I’ll circle back to microservices and how small they should be… or not.

If you’re only a couple of episodes into Cobra Kai seasons 5, don’t worry, it'll get better. I didn’t like the slow start either, but it ended strong – as it always does.

Eagle Fang!!!

Get great content updates from our team to your inbox.

Join 86,000 subscribers. GDPR and CCPA compliant.