Some of my teammates say learning for the single cloud makes no sense. It means that you are tied to that single provider. You are using provider-specific services and solutions and what if it disappears and you are left with nothing? Or what if the said provider will be uncovered as an evil organisation that kills little dolphins for a living and your conscience will not let you stay with them? All that means you would have to start all over again — another provider, yet another learning curve. And I couldn’t agree more.
So maybe you should start learning how to achieve scalability, durability and resilience on the low level, spinning up your own hardware machines, maintaining them, then Kuberneting the sh*t out of them. That would work.
Except it wouldn’t. If you’d achieve that level of desperation and go the windy and dark path of how things were made in the Middle Ages, it would take time. It would make you suffer, put you through a couple of deep depressions. Inevitably you would make a lot of mistakes, learn all the things hard way, spend a lot of money, neglect your family and friends. And then, when your children would already be 35-year-old strangers, then you’d be ready to start building some software on your beautiful, already outdated infrastructure! Your client is long gone bankrupt and you’ve wasted your life on reinventing the wheel.
Everything has changed. Cloud is a sign of times. You can’t avoid it if you want to be competitive. Just because everyone uses it, you have to do it as well. You can think it sucks but it doesn’t change anything. Why people use this devil invention, you ask? Because it makes them go a lot faster. This actually was one of the things that enabled the growth of so-called startups. I have an idea — BOOM! it’s online. It signs perfectly into Agile (or some would argue Lean) way of thinking. You need to deliver fast and you have the opportunity to deliver enterprise-grade infrastructure solutions faster than ever. You can then focus on the things that matter most (not in life, but in your job) — the software.
I mean — come on! Simple networking — with a few clicks you can have a bunch of private subnets scattered in different availability zones — no traffic comes in (because hello! no internet gateway with route table!) and guaranteed high availability (as availability zones are physically separated from one another). Of course, you also get network access control lists out of the box. So you clicked a bunch of buttons an orchestrate through a number of OSI layers — and this is only networking basics example. Imagine how long it would take you to achieve the similar result by building it yourself (not even mentioning the costs). It would take long enough to modify the design as well. With a cloud, it takes you a few minutes tops — and its free (AWS subnets I mean). A bonus in addition to a multitude of different services waiting for you to reach out for them.
With a cloud, you are empowered to provision literally any architecture at almost any scale. It will cost you of course, like with any real-life service. But not any real-life service gives you free tier you can play around — there is no free tier for my housekeeping service, sadly. With this Cloud-based free tier, you can actually run a small up to middle-sized application (almost) for free. Do you know any traditional hosting provider that will do that for you?
Is this knowledge really that specific?
Clouds are alike. Really. Different companies try to outrun the competitors by introducing more and more complete and sophisticated services. Then the rest of big cloud providers fills up the gap and goes an extra mile with another brilliant solution. And all of that is for your benefit (and their as well, of course). All of the cloud providers allow you to create VPCs, subnets, orchestrate networking, run compute instances, set up databases, configure failover techniques, run code as stand-alone functions, and much much more. Most of the services are managed by the provider so you don’t have to worry about maintenance, scalability issues, low-level infrastructure security — besides simple configuration the rest is taken off your shoulders.
If different cloud solutions are similar to each other, doesn’t that mean that, in a very generalised sense, they differ just by some implementational details? It’s a little bit like with two programming languages — they do have different syntax and a bit different functionality, but the basic building blocks are pretty much the same. In the end, all boils down to some servers in a network running some software. What’s more to it than that? Single services offered by providers seem to be more like abstract implementations of well-known ideas and patterns. So you just know how they work, really. You just have to use the right API.
What are the alternatives?
What are the alternatives you might ask? You can use standard hosting services and orchestrate rest of the solution by yourself, or go to some company that specialises in it. This is what the cloud companies are all about — they are like your local infrastructure provider (like there’s always one) but operate globally. Which also means that you can operate globally on top of the services made to your disposal.
You can of course work on abstracting things and make bootstrapping of your infrastructure platform-agnostic. Things like Terraform and Serverless will help you with that. But those are still just a kind of universal adapters with its own limits. Useful, but it’s still worth to know how they operate under the hood.
You can also learn about all the cloud solutions available — and that would probably be the best thing to do. Problem is, there are a few of those on the market. That means there is a lot to digest. But it’s still much easier than learning the low-level stuff. Then it would be advisable to know a few solutions, but I feel pretty confident you can stick with your preferred one — at least for some time.
So yes, tomorrow I’m about to get certified as an AWS Architect. The learning path provided me with a lot of knowledge and also explained some misconceptions I had on how some things work under the hood or can work when allowed to communicate with each other. With the cloud, like with programming languages, you always have to start with the first one. Then it gets easier over time. My strategy is to also get certified for one other platform because it’s important for me to have a thorough understanding of the differences between them as well as to stay competitive. This kind of knowledge is still rather seldom, especially on the professional level. There’s also that feeling that you are no more “just” a software engineer — suddenly you have those superpowers which let you create virtually anything — with just a few clicks. Well, actually you should avoid clicking as much as possible and preferably go for native infrastructure-as-code solution. But you see my point.