This is a rare article in that while I disagreed with its conclusions and most of its reasoning (yes, serverless is stupid if you believe the economics of software companies haven't changed since the days software was distributed on floppy disks), I still walked away appreciating it for some reason. I guess that it's interesting to consider the similarities between mainframe computing and serverless even if they are largely superficial.
> These systems took ages to compile, hours to run all the unit tests, and clearly interactivity went down the drain. So “split it all up” was not a bad idea. It was an unnecessary idea, mostly driven by the shortfalls of mainstream programming languages, but necessity is the mother of invention - even though your average Java business app was much simpler than the Smalltalk IDE before you added a single line of code to write your app, it was already too complex to maintain and “divide and conquer” was the answer. Service Oriented Architecture, and later microservices, was born. Split your codebase, split your teams, create a lot of opportunities for mediocre coders to grow into mediocre engineering managers, everybody was happy.
Maybe I'm misunderstanding, but it seems like the author misunderstands the raison d'etre of microservices. He seems to posit that they exist because of performance or complexity limitations in the host language, so we break them up, and because we break them up we also break up teams to work on them. Or something like that.
In truth, microservices are really just about embracing Conway's Law--your architecture will resemble your organization structure eventually whether you like it or not. So we empower teams to deploy and operate their own services instead of coordinating deployments with other teams and throwing issues back and forth over the dev|ops team wall. Notably, Go microservices are common, and like the author's SmallTalk example, Go services can compile and run tests in roughly a second.
We don't run microservices because of compile and/or test times, but rather because we're optimizing for the realities of organizations--the overhead of synchronization and communication--in a world where software isn't shipped annually in a shrink-wrapped box of CDs or DVDs but on every load of the webpage.
> The return of the Job Control Language this time was in the form of, again, configuration data on how to run your microservice. Microservices were somewhat fatter than the very fine-grained objects of the old days, so there was less of it, but still - it was there. The feedback cycle became worse as well: in the monolith-with-XML days, your XML editor would get you mostly there and a quick local compile and run would leave you all but certain that your configuration was working. XML, however, was universally rejected in favour of things like JSON, Yaml, HCL, Toml - all free of structure, with zero indication whether a computer would find your prose gibberish or the next Shakespeare play until you actually pushed your code to some test cluster. It suddenly felt a lot like being back at that university interacting with a mainframe, but at least you still owned the hardware and could introspect all the way down, especially if you were doing “DevOps” meaning mostly that you had administrative access to your hardware.
I'm confused on a few points. First of all, XML has structure but JSON/YAML/etc doesn't? Is the idea that Spring or whatever statically type-checks XML but that Terraform/CloudFormation/etc don't type check their configuration? I'll be the first to acknowledge that we would be better off with better type checking in infra-as-code, but there is some type checking. And certainly the ergonomics of these tools is rough and it will get better when we stop pretending that infra-as-code can be "as easy as a few lines of YAML!" and embrace the realities that we need to DRY this stuff up exactly like we need to DRY up our application code (and thus we shouldn't waste time poorly reinventing the abstraction wheel--looking at you Terraform and CloudFormation).
That said, is the idea that Job Control Language is analogous to an infra-as-code tool like Terraform or CloudFormation? Does it allow the user to declare the ideal state of the world and then reconcile it against the current state? I've never worked with JCL, but I'm skeptical. Maybe I'm missing the point here.
> Microservices have trouble scaling, and they are very complex. Most companies that employ them have no need for them, but the systems and programming languages they employ are sufficiently lacking that this stacking of complexity on top of complexity becomes a necessity.
Microservices certainly can be a lot of complexity, but I still don't buy that this is a limitation of programming languages. Again, you're trading technical complexity for the ability to spend less time coordinating with other teams, and the return on investment for this tradeoff will vary from organization to organization. This complexity will improve as the best practices become more firmly established and the tooling ecosystem improves.
> pparently, Worse Is Better and you can do worse than Virtual Private Servers, so through a short-lived detour through containerizing microservices and deploying them on a distributed scheduler like Mesos, Nomad, or Kubernetes, we have arrived at “Serverless”. You deploy individual stateless functions. But not inside a Java monolith, that is old, but on top of a distributed system. You would have been laughed out of the door if you had proposed that in 2000, and you should be laughed out of the door right now, but such is the power of marketing.
Again, the author doesn't seem to understand the rationale for microservices / devops / serverless. Even if his conclusion is right, he's not rebutting the actual premises for microservices. Virtual Private Servers, pets, don't scale. You can't get a big organization to maintain stateful servers well, so in the 2000s we had smaller Ops teams who would maintain the servers and any change had to go through them. Businesses don't like paying to build features and not being able to ship those features to customers for months. Further, debugging issues that arise from a massive monthly or quarterly integration of features is much more effort than the collective effort of debugging issues that arise from incrementally delivering features, especially when the stateful production environment is inevitably different than the stateful staging and dev environments. It's weird that the author clearly values fast feedback loops but can't appreciate how a daily or hourly feedback loop is better than a months- or quarter-long feedback loop, (especially for startups, where iterating to product-market-fit is paramount).
Yeah, you could have each team operating its own pet VPS running its own service, but that's pretty close to microservices. And you'll also realize that each team configuring its own process management, SSH configuration, firewall rules, monitoring, alerting, etc is kind of a lot of wasted effort and most developers aren't very good at or interested in that kind of work anyway, so it would be nice if we could have a pool of hosts that an ops-like team could manage which the development teams could deploy to and operate as they like. Congratulations, you're halfway to Kubernetes. If you can buy into the immutable/GitOps philosophy then you're pretty much all the way to Kubernetes.