[vbsteven]

I think the pendulum has swung a bit too far from its optimum with serverless and microservices. The main issue I have with both is the huge complexity and friction between how it runs on a developer machine vs how it runs in production.

For me the sweet spot is monolith(-ish) 12-factor applications packaged up in containers. In this setup I can just `docker-compose up` my dependencies (postgres, redis, rabbitmq, other services, ...) and run the application from my IDE against those (so I can use the debugger instead of printf-to-cloudwatch). For production I can package the app in a container and deploy to a container orchestration platform (Kubernetes, ECS, or something else).

To answer your question, what comes after Kubernetes?: I'm hoping for a platform that is somehow a consolidation of the good ideas that we've seen in Terraform/Pulumi/Kubernetes/Cmake/DockerCompose/Swarm. I want to write a portable idempotent "deployment build script" that I can apply against a cloud provider or bare metal or localhost in a similar way. With good support for different configurations depending on the environment (like C ifdefs or cmake options).

For example: when I apply the script against my localhost it spins up a postgres container, when I apply the same script against my AWS account it configures an RDS postgres instance. Both invocations will pass along the connection string to dependant services.

Basically morph docker-compose.yml into a portable Cmake for container orchestration.

[airhead969]

There are three main classes of services:

0. 12factor applications

1. Backend datastores

2. Infrastructure and miscellaneous, which is sort of turtles all the way down.

Disambiguating them is key to maintain proper infrastructure of any kind.

[lamontcg]

What I'd really like to hear is the story for after you're gone and the business has several hundred services spread out over 5-10 years of development, with varying historical stratums, and plenty of them being left on life support, where the business just doesn't want to pay barely anything to keep them running.

And then how does the teams dealing with cross cutting concerns like security, logging and monitoring deal with them.

[vbsteven]

I’m not sure what you are getting at. Several hundred services probably means going too far to the microservices side.

Cross cutting concerns like logging and monitoring are handled by 12factor. Services log to stdout and have the container orchestration pipe it to a logging backend. Monitoring can be standardised as well with healthcheck and metric endpoints. Security always has a maintenance cost attached unless you want to keep running on 12yo tomcat.

[lamontcg]

> Several hundred services probably means going too far to the microservices side.

You can easily hit that in a small fortune 500 company with ~10,000 employees, without microservices.

[devonbleak]

I'm pretty sure you just described the value prop for CloudFoundry.

Seriously though you're talking about another abstraction layer on top of whatever cloud provider(s) you're using. And the issue with such abstraction layers is that to really make them portable you're stuck with the lowest common denominator of features. Such a thing doesn't really play well with the immaturity and velocity of cloud providers - we need and use the latest features from the cloud providers and get stuck waiting for TF providers to add support. And that's just talking control plane - you also need abstraction layers for all your data plane interactions to homogenize those APIs.

Back in the day RightScale tried to do this but they consistently lagged support for AWS feature releases by upwards of 6 months making it a nonstarter (this was back when things like IAM and VPCs were just getting launched and critical features to make them usable were coming fast). CloudFoundry's approach is to provide an API to run everything on top of a compatible hypervisor control plane API - the lowest common denominator.

[vbsteven]

The abstraction layer with lowest common denominator is the tricky problem that The Next Big Thing will likely need to solve.

Terraform tries to do it but as you mentioned it’s often a frustrating experience because of lagging providers and Terraform itself is a moving target (at least it was 1-2 years ago). This quickly leads to code rot and dependency hell.

I think containers are the right abstraction for packaging, but orchestration wise we’re still trying to figure out the optimal workflow. K8S, TF and Ansible have shown idempotency is an interesting concept to have. Pulumi improves on that by having procedural logic to describe the desired state. And in my eyes The Next Big should build on those ideas while avoiding or fixing the current rot/lag/dependencyhell problems.

[victor106]

> For me the sweet spot is monolith(-ish) 12-factor applications packaged up in containers.

exactly this.

Once you go with this you take technology out of a microservices definition and all that remains is how you scope your service.....