Developers Heart Cloud Infrastructure

While we’re still in the early stage of Infrastructure-as-a-Service (IaaS) adoption among traditional IT departments and large enterprises, for developer-centric organizations, IaaS is already the default. Why is that, and why does it matter?

If your organization values great software development, it should matter. The best tools and best infrastructure empower your developer team to move faster and produce better quality code. Freeing them up from traditional concerns and inefficient processes enables them to focus on what really matters: Solving tough problems, innovating with software, and delivering what the end-user wants.

So why do developers love IaaS? Here are a few reasons:

Consistent Configuration

Configuration management tools such as Chef, Puppet, Ansible, and Salt are great for managing the configuration of an OS: an app’s environment, dependencies, etc. And now, with Docker, you can go a step further and manage the app’s environment with an immutable state. These tools all work anywhere: IaaS, your laptop, or anywhere in between. However, they don’t cover the “last mile”: the actual configuration of your infrastructure, a level below the OS. Networks, load balancers, virtual instances, etc.

With IaaS, you can code-define and control the full infrastructure layer. AWS does this with CloudFormation and other systems have similar, if less mature, tools. Wrap that together with a configuration management tool, and now the full system, from top to bottom, is managed with a consistent configuration. A nice side benefit… you can easily replicate the full stack for staging, or to deploy private environments

Dev/Test Servers are Cheap

With truly elastic infrastructure, a developer should never need to be limited by infrastructure: it’s just too cheap and too easy. A micro server on AWS costs $9/mo and can be launched in minute. And if you need larger servers, there are many methods for turning servers on and off only when you need them. Considering that the 40-hour workweek is only ¼ of a week’s 168 hours, this can result in dramatic savings. Even if a full-size staging stack for your app costs $1000/mo, you likely only need to run it for a few hours of testing before your weekly deploy, so you can easily turn $1000 into $1.39/hr.

CI & Automated User Testing with No Limits

A limitation of CI build environments can sometimes be build time. Even more commonly, automated User Testing, when run across a wide swathe of platforms and browsers, can be very resource-intensive. But tests aren’t useful unless they are done quickly. With IaaS, you can quickly burst your infrastructure to complete tests fast. If the task can be distributed, you can launch many servers. Or if it’s simpler to do it on a single server, you can launch something like the monster c4.8xlarge on AWS, and get 36 cores for $1.856/hr to complete your builds very, very fast.

With BugNet, Trek10 is building a highly scalable infrastructure for Automated User Testing. So no matter how many test cases you have to run and how many platforms & browsers you want to run it on, we can easily burst up to complete your tests quickly.

Design Innovative Systems

IaaS is not just about pay-by-the-hour virtual servers. If that’s what you’re using it for, you’ve barely begun to scratch the surface. There are unique tools that are much more powerful and compelling that simple virtual servers. Leveraging those services by deeply integrating them into your application’s architecture will dramatically improve your ability to deliver massively scalable, low-maintenance solutions, much faster. Some examples from the AWS world:

• Kinesis for data streaming: If you have distributed agents that are sending data back to a central point (such as an IoT system), Kinesis is for you. It durably stores your logs and allows you to ingest them with a worker system. Think of it as a message queue for big data, but with no servers to maintain or software to install. Just like a message queue, it allows you to decouple your ingestion and processing and produce a highly durable and highly scalable real-time big data system.
• Simple Queue Service (SQS), Simple Email Service (SES), Simple Notification Service (SNS): SQS is a simple managed message queue; SES obviously sends emails (among other approaches, you can simply point your app to the SES SMTP endpoint to handle your app’s email); SNS can trigger emails, SMS, push notification, or webhooks. All of these are fully managed and can be used together to provide basic components for your application.
• S3/CloudFront for central file storage: If your app accepts, for example, user uploads, leveraging S3/CloudFront is a no-brainer. This way, your web server contains no state and you can easily scale up & down web server nodes. It is quite straightforward to have files uploaded directly into S3. Then if you put CloudFront in front of the S3 bucket, you can easily serve up cached versions of the file with SSL, all under your domain name.
• Lambda: This service is a game-changer for application architectures. Basically, you define some application logic in a chunk of code (currently in node.js only, but support for more languages is coming) and then trigger execution of code from an “event”. Currently those events include an S3 object change or dynamoDB stream. But again, support for more to come. This would let you, for example, resize an image automatically when the raw version is dropped into S3. Many more use cases will become evident as support is added for more event types. The beautiful thing is, there is no server to manage… the code execution happens transparently and you simply by for the compute your task uses.