It's hard to believe, but 10 years ago AWS had only five products. Chief among them, of course, was EC2. Although it feels a little quaint now, back then EC2 was an incredible offering. Anyone could fire up a server in seconds, install some code, and transform that generic server into any service one could imagine.

And for most of the history of the internet, this has been the pattern. Take a server, write or download code to turn it into a service, and ship it. We've periodically introduced new abstractions with virtualization (and, if we're being accurate, EC2 is itself a virtual abstraction), but whether we called it a "server" or a "VM" or a "container" it was still pretty much the same-- a generic building block for our service to run upon.

The big drawback here is that lots of services are pretty similar. Most code isn't really blazing a new engineering trail, we're just assembling known solutions into newly composed products. This isn't to say that we don't add our own unique value to this process, but rather that our custom business logic is a relatively small percentage of the overall code that we have to ship to deliver something meaningful.

If you think about that for a minute, you'll realize that's actually pretty bizarre. Imagine if a pastry chef first had to farm wheat before they could bake a cake. Sure there are certain circumstances when controlling the fundamental building blocks is very important, but in general wheat is a commodity which is fairly interchangeable. The same is true of technology. There are times when you'll need to build a very bespoke solution, and in those times you'll create a lot of value, but most of the time the value isn't derived from creating the building blocks-- it comes from assembling them together. The master chef doesn't churn the butter, but they know which butter is best and how much is right. We should think the same way.

If you look at AWS's product catalog today, you'll notice that they have a huge variety of pre-built, use-case-driven products that you can pull off the shelf, configure with code, pay-per-use, and use immediately. The fundamental building blocks are services, not servers. (And yes, the services run on servers. Understood.)

The bottom line is: the model has changed and we're not really talking about it. And we should, because it has some pretty big ramifications. The biggest of which is the development environment.

Cloudside Development

If you've been writing software for a while you probably don't even think about this very much, but your laptop is a server. We kind of take that for granted. We've been building on servers for servers for so long that it's become subconscious. You can configure your laptop to mirror a server so closely that you can build transportable applications that move directly from your local development environment out to a production server with relatively little risk. But, and this is a big but, your laptop is not a cloud provider.

It's essentially impossible to replicate every AWS service locally. There are some attempts here and there to mock or fake services locally, but AWS releases products at a lightning pace and it's ultimately a losing battle. When services become the building blocks, local laptop development stops being a helpful approximation of production. And this breaks pretty much everything we take for granted in a server-centric world.

The right solution here is not to try to parody AWS on your laptop, but rather to embrace the fact that building against cloudside services is fundamentally done in the cloud. I worry that people will hear "cloudside development" and think I'm advocating for some kind of SaaS IDE where you're stuck writing code in your browser and deathly afraid of hitting the 'back' button. That's not it. Write your code wherever you like! But you have to write it against real cloud services.

The ideal cloudside development lets your local code interact directly with real cloud services in a live environment. It requires that developers have access to sandboxed developer environments in their cloud accounts. It necessetates sophisticated permissions schemes, parameterization of the configuration of these cloud services, and a relatively short cycle between editing code and knowing if it works. If it takes several minutes to deploy between each iteration, it's simply too slow.

Server-centric vs Service-centric

Amazon Web Services has passed $30 billion in annual revenue and is growing at 40%. Every single one of their fastest growing products are pre-built services. You can't argue with the numbers. It's official: we've transitioned from a fundamentally server-centric model, to a modern service-centric model.

Still trying to build applications locally before deploying? Then you're fundamentally missing a real development environment. Set up your cloudside development environment and prioritize more efficient workflows with Stackery today.