1 min read
Learn how Cloud Posse recently architected and implemented WordPress for massive scale on Amazon EC2. We'll show you exactly the tools that we used and our recipe to both secure and power WordPress setups on AWS using Elastic Beanstalk, EFS, CodePipeline, Memcached, Aurora and Varnish.
1 min read
Learn about some of the “best practices” for running a modern engineering organization that we practice at Cloud Posse. “Best Practices” are opinionated & proven strategies/tactics used to achieve some desired outcome.
These slides are a small part of what we think it takes to embrace a DevOps culture. It starts with the “Organization” embracing change and laying a foundation that will support the cross-disciplinary practice of DevOps.
1 min read
Secrets are any sensitive piece of information (like a password, API token, TLS private key) that must be kept safe. This presentation is a practical guide covering what we've done at Cloud Posse to lock down secrets in production. It includes our answer to avoid the same pitfalls that Shape Shift encountered when they were hacked. The techniques presented are compatible with automated cloud environments and even legacy systems.
5 min read
Over the last year, we're seeing yet another massive transformation in how software is delivered take hold. I will call this a “Paradigm Shift” – containers are replacing virtual machines as the fundamental unit of software delivery at an unprecedented rate.
Over the last year, we're seeing yet another massive transformation in how software is delivered take hold. I will call this a “Paradigm Shift” – containers are replacing virtual machines as the fundamental unit of software delivery at an unprecedented rate.
Apparently, Moore’s Law applies to the rate of adoption of new technologies as much as it does the density of transistors. The adoption rate of public cloud adoption is twice that of what we saw with Virtual Machines, and now we're seeing the same thing with container adoption. Enterprises are interesting species to study because they are the slowest to move and therefore a consistent barometer of change. Enterprises are learning to be more tolerant of change—this an awesome trend.
What are the ingredients for a paradigm shift? Let’s begin by looking at a few examples.
The concept of “Virtual Machines” had been around since the 60s, but it took until the late 90s for the technology to catch up. It wasn’t until VMware came out with their “VMware Workstation” product in 1998 that the concept got popularized and we saw mass adoption. What did they do? They made it easy—first and foremost for developers to run multiple environments on their desktops. Then they conquered the enterprise with tools.
The other prime example is “Cloud Computing.” It was not a new concept, it’s just that no one had really cracked the nut to show us how to do it properly. That was until Amazon came along. With EC2 they made it accessible and showed us the possibilities; they let us write infrastructure as code. The possibilities blew our minds! So everyone tried to copy what Amazon did, but unfortunately, it was a little too late.
That's because now we have the container movement. The concept of “Containers” is also nothing new. In Linux, the core functionality has existed since 2008 when Google contributed their work on LXC – the technology behind containers – to the Linux Kernel. However, it wasn’t until Docker came along circa 2013 (5 years later!) and made it brain-dead easy for developers to run them that we started seeing an uptick in their adoption. Now Docker is taking a page out of VMware's playbook by following up with Enterprise tools for production with the release of the Universal Container Platform (“UCP”) & and the Docker Datacenter (“DDC”).
The secret?
In the wake of all these transitions is some collateral damage. These are shims or training wheels we used to get from bare metal to containers. It's the result of the natural process of innovation.
So why is the move to containers happening so quickly?
Hint: It’s not strictly technological.
First, we can agree that the second iteration is easier, better, and faster than the first anytime we iterate. Simply put, everything is less scary the second time around. Moving from the classic “bare metal” paradigm to a “virtualized” one was a massive endeavor. It was the “first” major paradigm shift of its kind. It took convincing of both C-Level execs and wrangling of Operations teams. Since it was a foreign concept, there was severe skepticism and pushback at all stages. Flash forward 15 years later, and there’s now fresh blood at the top. There’s a new guard who has moved up through the ranks that’s more accepting of new technology. Enterprises have gotten better at accepting change. Moreover, the tools of the trade have improved. We’re better at writing software — software that is more cloud friendly (aka “cloud native”).
Here are my predictions for what we'll see over the next few years.
1 min read
Kelsey Hightower, a Google Developer Advocate and Google Cloud Platform evangelist, recently gave a very helpful screencast demonstrating some of the tips & tricks he uses when developing Go microservices for Kubernetes & docker. Among other things, he recommends being very verbose during the initialization of your app by outputting environment variables and port bindings. He also raises the important distinction between readiness probes and liveness probes and when to use them. Lastly, in the Q&A he explains why it's advantageous to use resource files instead of editing live configurations because the former fits better in to a pull-request workflow that many companies already use as part of the CI/CD pipeline.
3 min read
Heroku has deployed more services in a cloud environment than probably any other company. They operate a massive “Platform-as-a-Service” that enables someone to deploy most kinds of apps just by doing a simple git push. Along the way, they developed a pattern for how to write applications so that they can be easily and consistently deployed in cloud environments. Their platform abides by this pattern, but it can be implemented in many ways.
The 12-factor pattern can be summed up like this:
Treat all micro-services as disposable services that receive their configuration via environment variables and rely on backing services to provide durability. Any time you need to make a change it should be scripted. Treat all environments (dev, prod, qa, etc) as identical.
Of course, this assumes that the cloud-architecture plays along with this methodology for it to work. For a cloud-architecture to be “12 factor app” compliant, here are some recommended criteria.
