This chapter provides a high-level look at what AWS OpsWorks is, where OpsWorks came from, why it came to be, and why the service is important. One of the key drivers behind OpsWorks is something called DevOps, which you may or may not be aware of. In this chapter, we will take a quick look at the DevOps role, and also explain who will benefit the most from using OpsWorks.
As you may have guessed from the title, this book is about AWS OpsWorks and how it can be put to practical use so that web applications can scale with minimal effort. OpsWorks is a Chef Framework solution for application and infrastructure management. Using AWS OpsWorks, DevOps teams can systematically manage, deploy, and scale global infrastructures and applications faster, and with much less effort in comparison to previously used methods.
OpsWorks is one of the many services provided by Amazon Web Services (AWS). The thing that stands out about OpsWorks is that it allows you to bootstrap complete environments that contain other AWS services. For example, with OpsWorks, AWS services such as EC2, ELB, EBS, Elastic IP, Security Groups, Route 53, CloudWatch, and IAM can all play a part in its configuration.
Managing the configuration of several services at once and in advance provides for automated deployment of applications and the infrastructure that supports them. Accessing OpsWorks involves having an AWS account, then navigating to it using the AWS Management Console by going to Deployment & Management | OpsWorks as shown in the following screenshot:
To date, OpsWorks has four defining areas which all work together in providing configuration management for scaling web applications. These areas are briefly defined in the following paragraphs.
At the highest level, OpsWorks uses something called stacks. There are many possible uses for this high-level item, and one such use could be as a stage within a multistage environment (think test, staging, production, and so on.); a single stack could represent the staging environment. In the example of a stack called staging, the stack would serve as a container, which includes configuration settings for enabling layers, instances, and apps.
The second level of OpsWorks is called layers. A layer is a blueprint for EC2 instances, EBS volumes, load balancers and so on, which function in a specific way. Layers define which packages and applications are installed, and how they are configured. An example of a layer is a Rails app server. The Rails app server includes configuration items such as the Ruby version, (which Rails stack to use), the RubyGems version, and whether or not to manage a particular version of Bundler.
At the third tier, OpsWorks provides a method for launching and managing instances. Instances are the EC2 instances that serve applications and data, balance traffic, and so on, in accordance to the configuration of their parent layer. As instances are launched, they will show up in the EC2 section of the AWS Management Console.
At the fourth level of OpsWorks are the apps. An app is application code that you want to run on an instance. Apps hold configuration information, which is required to deploy application code to application server instances. With an app, you define what code base it is (PHP), where it resides (GitHub), and what domain names it should be associated with.
AWS OpsWorks wasn't always a part of AWS. Actually, OpsWorks was originally a product called Scalarium, which was created in July 2008 by Berlin-based startup Peritor. AWS acquired Peritor in 2012, which then launched a modified version of Scalarium called OpsWorks in February 2013. AWS then discontinued Scalarium in August 2013, while providing a migration path for its existing customers up until that point. Founders of Peritor Scalarium included Thomas Metschke, Jonathan Weiss, and Mathias Meyer.
AWS recognized that Scalarium had strong capabilities that were broadly useful to AWS customers, and they've done an excellent job to date in transitioning and building upon the new service. As AWS continues to rapidly deploy new services and features, one can only assume that OpsWorks will eventually be tied into the majority of them.
So, you might still be asking yourself how and why OpsWorks is important anyway. Good question!
OpsWorks is important for several reasons. First, OpsWorks is a service native to AWS and because of this, it works seamlessly with other AWS services that it supports. Status information and callback response with services such as EC2, ELB, EIP, CloudWatch and so on, are updated in real time. This means that as changes are initiated to infrastructure, callbacks to the OpsWorks console happen immediately so that users don't have to wait for status updates prior to moving forward with other changes or additions.
Secondly, OpsWorks provides the ability to create full stacks, which can then be cloned into other stacks. This is extremely efficient for infrastructure development. For example, it allows individuals in a DevOps role to build a complete staging stack that includes layers and instances which are configured using Chef, then clone it to production, and then with the click of a button, bring an entire production environment, including applications, online within minutes.
Another very important aspect of OpsWorks is auto scaling . Auto scaling allows you to scale EC2 capacity up or down automatically according to predefined conditions. With auto scaling, it's possible to ensure that the number of Amazon EC2 instances you're using increases seamlessly during demand spikes to maintain performance, and decreases automatically during demand lulls to minimize costs.
Auto scaling is particularly well-suited to applications that experience hourly, daily, or weekly variability in usage. With OpsWorks, there are two distinct auto scaling options: time-based and load-based. This practically allows any flexibility with auto scaling that a DevOps team might require in meeting the demands of a rapidly growing business.
One other important feature of OpsWorks is application deployment. OpsWorks can be configured to automatically deploy application code from source code repositories hosted in Git and Subversion repositories, as well as S3 and HTTP archives. Members of a DevOps team can update code in a repository or archive, and then deploy the updates simultaneously across all application servers with the click of a button. This is a very powerful feature that solves the problem of maintaining code version consistency across servers.
Yet another very important feature of OpsWorks is disaster recovery (DR). With OpsWorks, systems can be architected so that they're region agnostic. This means that an entire network of instances can span multiple regions and also multiple zones within the AWS cloud. In this type of a configuration, an entire AWS Region could fail and a business application can continue to run. Auto healing , which exists at the layer level, is another DR feature of OpsWorks. When auto healing is enabled, instances can fail and OpsWorks will automatically replace them in their entirety.
DevOps...that term that is being thrown around these days. DevOps, a portmanteau of Development and Operations, is typically a software development methodology that stresses communication, collaboration, and integration between Development, Technology Operations, and Quality Assurance. There are varying ways of how this method is implemented, and in the case of AWS OpsWorks, DevOps refers to a team of individuals that has experience with all three facets of the business at hand. The following figure is an illustration of how the DevOps method is ideally situated:
In this scenario, a DevOps team communicates with Developers and Quality Assurance to ensure that application code is ready to be released to the servers that support it. DevOps can then deploy the code using the OpsWorks deployment features. DevOps also plays a role in communicating with Operations to ensure that the infrastructure in question effectively supports the application code that Developers are working on.
Internet startups that are looking toward rapid growth and scaling should consider OpsWorks as the platform for their applications. With OpsWorks, businesses including startups can look forward to the following for powering and protecting their infrastructure and applications:
Bootstrapped learning through familiarity with AWS
Tight integration with other Amazon Web Services
The ability to easily build and deploy distinct system environments, that is; test, staging, and production
Fine grained control over infrastructure
Infrastructure auto scaling
Automatic deployment of application code across many servers
Disaster recovery through intelligent architecture and auto healing
As you can see, any organization including Internet startups that are looking to effectively deploy, manage, and scale their infrastructure and application code will benefit from the use of OpsWorks. As the two worlds of System Engineers and Developers continue to meld, services like OpsWorks will become increasingly prevalent. For any other requirements that don't involve the previously mentioned elements, simply using the EC2 console for launching and managing individual EC2 instances, EBS volumes, EIPs, and so on will suffice.
OpsWorks is a tool that was designed by a third-party company with the goal of making it easier to both integrate and scale AWS services using Chef. AWS recognized this tool as a bit of a game changer, and then acquired the technology so that they could bring even tighter integration with native services to allow a DevOps team the ability to configure, deploy, manage, and scale infrastructure and applications easily using the AWS cloud.
In the next chapter, we will get acquainted with AWS and OpsWorks by walking through the setup of an AWS account, and then move on to the OpsWorks dashboard.