One of the constants in the tech world is that the marketing and sales folks want to make hard things easy in order to net more sales. One of the other constants is that the tech folks push back because many topics cannot properly be simplified, and by trying to make them simpler, we introduce bigger problems. Some areas are actually better left alone.
The readily available example of this might be the CLI. If you want someone to be able to perform simple tasks, give them a menu system. If you want them to be able to do the harder, more intricate work, give them a CLI. At a certain point, hand-holding becomes impossible. But I’ve waxed on that topic before.
The quest for one-click solutions to difficult problems is eternal. You could say that development environments such as Heroku fit that mold, as do Docker and (to a lesser degree) virtualization. There’s a lot of benefit in these solutions, but plenty of barriers as well.
We’re seeing the same simplifications in cloud infrastructure services that have matured to the point where they’re not offering only server instances, but entire, prebuilt application stacks ready to be clicked once and brought into the world. WordPress? Drupal? PHP? LAMP? Rails? Redis? Hadoop? Click here, and you’ll have a fully load-balanced stack with some kind of database back end ready to go. These aren't single server instances with everything pre-installed. They’re multitiered stacks designed for scalability and heavier loads.
This isn’t a bad thing. For greenfield projects, it’s a timesaver. You don’t have to make sure you configure your database properly or set up the load balancing. You don’t have to worry about server sizing or application installation. You don’t have to run the initial setup steps that some apps require. You click and go.
But it’s usually not that simple. The app you need to run isn’t available, but requires a LAMP stack, so you fire one up. Naturally, a handful of the required packages is missing. You don’t get your choice of distribution, so if you didn’t expect Ubuntu, you’re stuck with it. The app wants to install in one place, but the stack config says otherwise. You need to dig around to find the proper settings for the MySQL instance, then go through an unfamiliar control panel to perform basic tasks because you can’t access the SQL server directly yet.
Your app has a full installation guide, but because the stack has done much of that for you, you need to pick through and determine which steps to perform to get a working installation. Oh, it turns out you need Nginx, not Apache? PostgreSQL not MySQL? Too bad. This list could go on and on.
When all is said and done, it’s entirely possible that standing up the “ready to roll” prebuilt stack took more time than a baseline build, and you’ve had to make so many concessions to the stack boundaries along the way that the result is a one-off installation that doesn’t mirror the local development environment at all. Worse, you’ve had to rework the stack build so much that it’s become an impediment. The prebuilt stack that looked so inviting has in fact required exponentially more work in both the short and long term.
This is clearly a devil’s advocate scenario, but it’s common enough. Prebuilt stacks are designed for the common denominator or for temporary usage or to get a greenfield infrastructure going very quickly to facilitate rapid development. For those purposes, they are excellent choices. For others, they’re definitely not, and it’s better to understand that before you burn hours and hours, only to realize you need to start all over because the list of integration issues with the prebuilt stack is overwhelming.
As with the CLI example, if your needs are simple, so is the solution. If your needs are complex, most likely, so is the solution -- you’re better off building it yourself.
Which leads to custom stack templates: Custom stacks, which you can build with the likes of AWS CloudFormation and Azure Resource Manager templates, can be great resources for a much broader audience. The ability to spin up service and app cloud stacks, fully tiered, with a few clicks is pretty great -- if you have both the need for such rapid deployment, and the time to construct and maintain those configurations. Note that this isn’t necessarily only server instances built from images, but the whole works, including prepopulated SQL database instances, load balancing, orchestration, you name it. When you don’t need it anymore, tear it down.
Clearly, custom stack templates can be a huge timesaver in a development environment. We’ve been doing that for years with local virtualization, and it’s equally as suitable to the cloud.
A wise man once coined the term TANSTAAFL: There Ain’t No Such Thing as a Free Lunch. Beware those who would tell you otherwise.