Are you treating your servers like snowflakes or rubber stamps?
ann_marie_99 06000073UA Visits (11135)
I was inspired by this entertaining article by Alex Tatiyants: DevOps is Ruining My Craft.
A favorite analogy in the DevOps community is that the “old style” of IT server management, where people can make manual changes to their servers, leads to production servers that are unique and precious, like snowflakes. If you don’t completely automate the configuration of your servers, your chances of re-creating the exact same server twice are nearly zero, just as no two snowflakes are alike. And because you can never re-create a production server, you must do everything in your power to protect it from changes that can break it.
The problem with this approach is that it creates an adversarial relationship between developers, who want to change the servers often to release new features, and operations professionals, who want to keep the servers running and safe. Operations teams tend to “lock down” the production servers and only allow changes to them on rare occasions. This makes business-critical software less agile and more difficult to change.
So what’s the alternative to servers as snowflakes? Servers as rubber stamps! We advocate automating everything, so that your servers can be re-created on demand. Do you want another web server? Ca-chunk, here you go. Do you want another web application server? Ca-chunk, no problem.
Creating a new server for each release of new code, and replacing the old server with the new one, simplifies “rolling deployments” into production and other techniques that DevOps advocates recommend.
Do you want to add a new web application to your site? Stamp out a new web application server with the new application on it, test the new website in a staging environment, re-configure the tested server so it’s available in your production server pool, and then redirect your web traffic to go to the new server instead of the old one.
Cloud computing is the enabling technology that makes “rubber stamp” servers easy. While you can automate the configuration of standalone servers, it’s dramatically simpler to automatically create and configure new servers in a cloud for every code change. When you start with a clean virtual machine image every time, the new systems that you create will be almost identical to one another when they start up. When you then automate every step of the configuration process with infrastructure automation code, you can be sure that your systems will be configured in a repeatable way.
These techniques have already been put into practice by other DevOps leaders, including Etsy, Facebook, and Flickr. At IBM we’re developing new tools and integrations between existing tools, to make DevOps principles and practices easier for our enterprise customers to adopt. One such solution is IBM SmartCloud Continuous Delivery, which we’re developing now.
I work on the IBM SmartCloud Continuous Delivery development team, and we are using SmartCloud Continuous Delivery to build SmartCloud Continuous Delivery. For example, we use Rational Team Concert with our Continuous Delivery plug-ins as our development environment, and we use our Continuous Delivery build definitions to automatically create new test servers in the cloud every time we deliver a code change.
IBM’s Virtual System Patterns make infrastructure automation even easier. Rather than starting with virtual machine images, we start with pre-configured patterns that already include the prerequisite software for our application. These patterns are available with IBM Workload Deployer today, and they also will be available with the new IBM PureApplication Systems and the next version of SmartCloud Provisioning.
You can think about a Virtual System Pattern like a rubber stamp for virtual systems. For example, if your production system includes multiple WebSphere Application Servers and DB2 servers, you can use this Virtual System Pattern as a starting point:
There’s a lot of detail in this screenshot, but here are some of the more interesting things that this Virtual System Pattern handles for us:
Starting with a Virtual System Pattern is useful because it saves developers from having to worry about everything listed above. Also, those systems have already been optimized for the best performance, reliability, availability, and security by someone with real-world operations experience. Finally, using a pre-defined pattern reduces the number of different configurations that the development and operations teams need to support. We don’t even need to write installers for applications that only need to run in our cloud environment; we just write automation code that assumes we’re creating a brand new server, and we can make assumptions about what’s already installed and configured on the server. That saves us time that we can use to do more important things.
Creating and configuring new servers in the cloud is also orders of magnitude faster than the same activities outside a cloud environment. Most of my team’s test systems (which usually include 1-2 VMs) are up and running within 15-30 minutes after a developer delivers new code. That includes building the application and infrastructure automation code, publishing it to the software library, provisioning and starting multiple VMs, installing and configuring the prerequisite software (like the application server and database) on all of the VMs, installing and configuring our application on the correct VMs, starting all of the services, and even testing the running servers! We can do several of these deployments in parallel as well, and it’s not unusual for my development team to run through this entire automated process several times every day. And when we’re done with test systems, we can automatically delete them.
There will always be a need for some long-running production servers, and some applications don’t lend themselves to this type of deployment as well as others. However, creating new virtual systems for every code change is ideal for development and test teams, and that’s why we started with development and test tooling for SmartCloud Continuous Delivery. We’re currently working toward our first betas for SmartCloud Continuous Delivery. Over time we hope to extend our DevOps tooling support to enable more extensive operational testing, deployments into production, and incident management.
We’ve seen how SmartCloud Continuous Delivery, along with Virtual System Patterns, can help create and test new virtual systems automatically. SmartCloud Continuous Delivery is designed to get rid of the bottleneck caused by waiting for someone to set up new test servers. It allows us to test a running multi-server system after every code delivery, and when we do that, it’s much easier to catch bugs and fix them earlier. Finally, when operations teams are confident that new code has been tested well, they can allow developers to release changes into production more often. This allows businesses to be more agile and react to change more quickly.
Goodbye, snowflakes. Hello, rubber stamps!