Golden Environments
Photo by Paul Green / Unsplash

Golden Environments

Developers have quite a few good options today to host applications on the web. Fly.IO, Render.com, Heroku and other PaaS (Platform as a service) providers do a very good job in helping to release code with a simple git push. Good part about using these tools is that no one needs to know a thing about configuring servers, storage, compute, network and so on. As long as you can comply by the rules and protocols of the platform, you are good to go.

These PaaS providers provide standard environments to run a service. They provide a certain specific workflow to increase storage, scale up or down a service and few other commonly performed operations. We can call them as "Golden environments". And one can live with the setup for quite some time until their userbase grows & hit the ceiling on how much they can customise such golden environments to match their growing needs.

They hit the ceiling on

  1. Price
  2. Performance
  3. Customisability
  4. System architecture allowances

PaaS tools might have been a huge time saver in the early days. But when developers want to outgrow such PaaS providers, they have limited customisability and become insanely expensive!

To grow further, developers can move one level down to signup for IaaS (Infrastructure as a service) providers such as AWS, Google Cloud Platform or Azure and start hosting their applications in them.

In IaaS providers such as AWS, one has to deal with VPCs, Subnets, Security Groups, NAT gateways, Internet Gateways, EC2 instances and so on to bring 1 server to expose their service. All on Day 1. They are exposed to the different internal elements (& complexities) of the golden environments that are otherwise built and kept ready to use by the PaaS providers.

Switch from PaaS to IaaS is not possible to do overnight. There is a ramp up time involved within any organization to up skill developers to use IaaS, hire new DevOps personnel, setup new processes (deployments, scaling, monitoring, alerting etc.,) to setup & manage app hosting environments.

IaaS providers help developers in someways to handle this ramp up time by providing services with higher level abstractions. Still, with the growing number of primitive services within the IaaS providers, this transitionary help is not fully realised in practical terms. There is still, simply so many services, configurations to deal with.

There is a ramp up time in between leaving PaaS and settling down on IaaS fully with a full blown DevOps team, toolchain and processes.

Ideally, those golden environments that helped someone grow from initial stages, need to be customisable to the depth of IaaS, in an incremental fashion. So that teams can go down to any depth on configuring infrastructure, when they want it and when they are ready with respect to time & effort.

EaaS (Environments as a service) providers can help here. With EaaS, developers can start with signing up for an IaaS provider (say AWS) and connect it with an EaaS provider to get golden app environments setup on the IaaS provider from day 1. These golden app environments can start providing pretty much the same value as a PaaS, but all on dev's own IaaS account. EaaS would let them customise such golden environments in far more greater ways than a PaaS would allow but in far more simpler & incremental ways than what IaaS providers demand.

With EaaS providers, Devs can stop worrying about infrastructure details, in the same way as using a PaaS but can also grow on to customise the environment with details as their user base grow and when their team is ready to tackle such complexities.

There are quite a few good EaaS providers today such as release.com, qovery.com. How well these players

  • simplify the first baby steps of devs
  • expose IaaS options when required,
  • automate dev/release workflows and
  • save time for the teams

makes them better than other players.