Deploying Kubernetes clusters in increasingly absurd languages
leebriggs.co.uk
leebriggs.co.uk
How about some Pascal? https://github.com/jaxxstorm/pulumi-examples/pull/96 Or maybe Emacs Lisp is more your flavour? https://github.com/jaxxstorm/pulumi-examples/pull/95
Or the pièce de résistance: Brainfuck: https://github.com/jaxxstorm/pulumi-examples/pull/97
> Although Brainfuck programs, especially complicated ones, are difficult to write, it is quite trivial to write an interpreter for Brainfuck in a more typical language such as C due to its simplicity. There even exist Brainfuck interpreters written in the Brainfuck language itself.
https://github.com/arthaud/c2bf https://github.com/felko/bfpy
honestly its a shame it fell by the wayside.
Though I learned on BBC BASIC so my idea of what counts as absurd as a first language may, of course, be questionable :D
Not saying it’s without utility, but to the mainstream: pants on head bonkers.
Head on bonkers boots embedded systems and servers, coordinates builds, ...
http://hermit1.scsys.co.uk/~matthewt/pulumi
(for anybody uninterested in my perl stupidity, please skip to the 'use Pulumi;' line which is the start of the actual user written code - everything before that would in a sensible world be a library but I wanted to present the example as a single file so chose violence ;)
App Engine Flexible was another one of these products that just needed a container that responded on certain ports, it was quite fun to get it working. But I ended up writing a tiny "compiler" that would compile a small subset of Python to whitespace since writing just whitespace itself was quite challenging, obviously.
I wanted to release it on April Fools Day but my manager was totally against it because April fools had become its own serious entity in the marketing org and he didn't want me stealing their thunder ( these days Google has dropped April Fools jokes altogether, I guess it got a little played out).
This is hilarious and not at all surprising
RIP My Little Borgmaster: Production is Magic
It's almost like someone had a bad idea and put XKCD and Xzibit in a blender...
Companies with ample cash will be fine, of course, but all these spurious startups with egregious VC funding, overpaid Pulumi and Kubernetes and <insert all the other unnecessary tech> engineers will soon be out of work and unable to find similar employment comp.
People who get shit done and can run lean profit driven businesses will continue to survive just fine.
> Low interest rates in 1998–99 facilitated an increase in start-up companies
> In 2000, the dot-com bubble burst, and many dot-com startups went out of business after burning through their venture capital and failing to become profitable.
Sound familiar? It should, because history rhymes.
People have seemingly predicted 20 of the last 1 tech bubbles. The "Dot Com Bust 2.0" headline is practically a meme at this point. I feel like it's something lazy journalists do on slow news days. Here's a brief sampling from the last 8 years.
From 2014 - "In Some Ways, It’s Looking Like 1999 in the Stock Market"[1]
From 2016 - "This Tech Bubble Is Bursting"[2]
From 2018 - "Silicon Valley tech bubble is larger than it was in 2000, and the end is coming" [3]
From 2020 - "6 Reasons This Tech Bubble Is Bursting"[4]
Ad infinitum.
[1] https://www.nytimes.com/2014/03/30/business/in-some-ways-its...
[2] https://www.wsj.com/articles/this-tech-bubble-is-bursting-14...
[3] https://www.cnbc.com/2018/05/22/tech-bubble-is-larger-than-i...
[4] https://www.fool.com/investing/2020/09/10/6-reasons-this-tec...
Companies relying on crazy market valuations will pop just like they always did. Companies with sufficient revenue OR cash should continue.
Kubernetes is fine and it's not _unnecessary_. It's absolutely crucial to many companies and having this tech available has solved many problems. It creates other problems, of course.
People like to complain about Kubernetes, but my viewpoint is that microservices is the unnecessary tech here. Sure, some stacks may benefit, but I'm willing to wager that most companies are not doing microservices, they are actually creating distributed monoliths just to be able to ship their org chart. And, in the process, adding all sorts of technologies that shouldn't be necessary.
It’s not just that of course. It’s the entire web toolchain and build pipelines, SPAs, react, node/npm, that entire community reinventing “SSR” and caching.
It’s the “modern data platform” movement where people stop using databases and slap everything into python and 10 layers of ETL and job queues and dags all so it loads into a cloud data platform with a separation of storage and compute at the end.
It’s all a bunch of crap is my issue and why I call it a bubble. Nobody is solving actual business problems. They’re just creating tooling and then new companies to make that tooling less insufferable.
As one tiny example, how much of say Datadog’s revenue is coming from overfunded VC companies who have never considered cost or utility. Those logs should have been sent to /dev/null in the first place is usually the answer.
> Nobody is solving actual business problems.
I think most people are solving business problems and that you're (perhaps justifiably) jaded on the tech side of it.
The entire CNCF doesn't solve a single business problem. And I say this while working with K8s since 2016. Not once has a customer thanked me for my tech stack.
You and the parent are probably talking about different people.
Hmm, I disagree with that assertion. Yes, a customer isn't going to thank you for making an investment in depending on open standards. But it's often a worthy investment because it lets you hold other vendors you depend on accountable. I've seen this firsthand with OpenTelemetry and the Observability space, where it's not uncommon for vendors to lock you in and get weird and shitty with you. I'd love to live in a world where that didn't happen, but in this case I think there's a very real business problem being solved.
Not sure about Pulumi, looks like they only have a series B 1.5 years ago. Either they have a very short runway at this point or found some real ARR.
Also how many IAC vendors are there really? Hashicorp, Pulumi and AWS? What are the others?
As I recall before cloud era infrastructure on any kind scale was still code, its just that the code was maintaining thousands of lines of Kickstart of FAI configs and associated preinstall and postinstall shell scripts. I don't remember that being any more pleasant to maintain.
What OP is getting at is that IAC is often not /sold/ this way, it's sold as way to make managing complex systems simpler, in the sense that someone with less expertise can use it effectively, because marketers and salespeople love promising something that will remove all that pesky setup work and let you start on whatever it is you actually want to do. This can be true for some tools (e.g. I don't have a great deal of knowledge about compiler internals or assembly, but my compiled code still does what I wrote it to do), but not necessarily all.
Managing an AWS environment is an inherently complex task, and IAC tools can't reduce that complexity without being prescriptive. We may in the distant future get to the point where prescriptive configuration is fine (I trust that my compiler will make better assembly optimization decisions than I ever will), but we're not there now. What we have now addresses UX issues with using GUIs for these tasks.
i've tried to fight this by leading by example with https://dhall-lang.org/ but apparently having a configuration compiler is too much... unless the compiler takes yaml as input, then it's fine.
I hate yaml as much as the next developer, but I've met plenty of folks who far prefer it to using a "real" language. Different strokes for different folks?
The challenge from a product standpoint is how to balance these different ways to do something without (a) ostracizing one group, and (b) creating a confusing mess on the "get started" path.
In the case of IaC, what the customer really wants is a programmatic way to generate instructions for Pulumi to use to build infrastructure. The dream of "declarative" anything is to explain what you want and have a machine make it reality, right? But in practice that's hard to do. The machine needs to be very, very smart.
But it's not that smart. So we cheat and invent non-programming-languages, so that people end up telling the machine in far too much detail what they want. Do I really want to tell the machine to "go in a loop creating resources as long as there are resources in a list" ? Or do I really want to do some other thing, and making these resources should just be an incidental part of that that I shouldn't have to explain at all?
Programmers who like YAML for anything other than pure data serialization don't actually like YAML, they just like that they can cheat with it. No need to write a configuration format if you read your configuration from it. No need to write a DSL if you execute logic based on it. The programmers who don't like YAML wanted to do the same things, but were bitten by all the problems that came from using the wrong thing for the wrong purpose.
So really, the product person and experienced engineer need to work together to prevent this whole situation from ever occurring. Create a schema, and create libraries that can generate YAML based on the schema, but do it in such a way that no human would ever want to edit it by hand, and too complicated to ever write a generator for it without the schema. This way the customer can't shoot themselves in the foot, or demand changes which would make everything worse.
It's not unlike LISP's predilection for sexpr-based DSLs, I suppose.
Starlark -> protos -> k8s api. Jic you wanted more confuse
The CUE support in particular looks fairly interesting, because I think it is going to end up being the universal translator for a bunch of these golang tools due to its ability to pull in types directly from code.
I found the Fortran example very interesting. I guess it makes sense modern libraries would be available.
https://en.wikipedia.org/wiki/Brainfuck
Example: ++++++++[>++++[>++>+++>+++>+<<<<-]>+>+>->>+[<]<-]>>.>---.+++++++..+++.>>.<-.<.+++.------.--------.>>+.>++.
Certainly it wasn’t only about being able to compile all sorts of esoteric languages down into a YAML-based data representation - though it’s fun to see the results of that here :-).
Our goal at Pulumi has really been to offer the best tools for infrastructure as code, and for defining and managing cloud infrastructure more generally, for any developer working with the cloud.
We started with a focus on the high-end - teams managing significant complexity of cloud infrastructure to get the most they can out of the managed services their cloud providers are making available as building blocks. We’ve grown with this part of the market, with great adoption and usage across many of the most advanced cloud engineering teams.
In order to grow with these users, we’ve invested in many layers of the Infrastructure as Code stack. Some of those improvements have been related to the software engineering benefits of using traditional general purpose programming languages to manage cloud infrastructure - IDEs, types, abstraction and reuse, test frameworks, packaging and versioning and so much more. But we’ve also been making improvements at many other layers of the stack. Our cloud deployment orchestration engine is now, I believe, the richest option in the market - with multi-cloud support, built-in secrets management, refactoring support with aliases, rich controls over replacement behaviour, built-in support for components, and much more. And our native providers for Azure, Kubernetes, Google Cloud and AWS are the most complete and most up-to-date providers for managing those cloud platforms.
We wanted to be able to offer all these benefits to the broadest possible range of developers working in the cloud. Since we already have very rich programming language options, we wanted to add an option at the other end of the spectrum - the simplest possible interface we could to the Pulumi platform. And that is what Pulumi YAML is. It is very simple, and designed for small scale use cases (a few to a dozen resources). It composes with the rest of the Pulumi ecosystem, so it’s easy to push complexity into components built in other Pulumi languages, to reference outputs of stacks deployed by other Pulumi languages, or even to "eject" into another Pulumi language if the complexity gets too high in YAML. So unlike many other IaC ecosystems where YAML or a DSL is the only option, in Pulumi, YAML can be a nice solution for simple use cases, without having to be abused for the complex use cases that are already well served by Pulumi’s existing alternative programming language choices.
There’s more details on all of these points at https://www.pulumi.com/blog/pulumi-yaml/ for those interested in learning more!