Cloud computing promises to be simple. Starting here and there a virtual server and the own virtual cloud infrastructure is ready. Those who think that I’m right with the statement are totally wrong. Virtual servers are only a small component of a virtual infrastructure at a cloud provider. A few virtual machines aren’t a cloud. The complexity sticks in the architecture of the application. And thus in the intelligence that the architect and the software developer included. That this is sometimes not implemented, the one or the other cloud user have showed us more than once impressively. Regularly the same suspects fail when their cloud provider is struggling with himself. Cloud computing ist not simple! I do not mean simple software-as-a-service (SaaS). I am talking about infrastructure-as-a-service (IaaS) and platform-as-a-service (PaaS), and here even granularity about the premier class named scalability and high-availability. And that’s what you should understand and fully take into account if you want to use cloud computing successfully, away from the marketing of the cloud providers.

Software-defined Scalability and Software-defined High-Availability

Currently new terms circulating through the IT stratosphere. Software-Defined Networking (SDN) and Software-Defined Data Center (SDD). A SDN introduces another level of abstraction above the network components. Typically, each router and switch has its own local software through which it is supplied with intelligence by programming. The network administrator tells the router, for example, under what conditions which packet should be routed or not. Within a SDN the task of incorporating a local intelligence for each component is eliminated. The intelligence moves one level up into a management layer in which the entire network is designed and each rule is defined centrally for each component. If the design is completed, it will be rolled out across the network components and the network is configured. With a SDN it should be possible to change a complete network design by “push the button” directly without having to touch each individual component.

The idea of the SDN concept must also be taken into account mandatory when using a cloud infrastructure. Because the use of a PaaS, but much more of an IaaS means a lot of self-responsibility. More than you might think at first glance. To start one or two virtual machines does not mean that one uses a virtual cloud infrastructure. There are and will remain two virtual servers. An IaaS provider only provides the components, such as the aforementioned virtual machines, storage, and other services plus APIs with which the infrastructure can be used. Bottom line, to put it simply, an IaaS provider only supplies its customers with the appropriate resources and tools in order to build their own virtual infrastructure respectively own virtual data center on the providers cloud infrastructure.

One must therefore ensure with software (the own application) that the cloud infrastructure scaled if necessary (Software-Defined Scalability, SDS) and in the event of a failure of a cloud infrastructure component a replacement component (eg, virtual machine) is started and is thus replaced (Software-Defined High-Availability, SDHA). The software therefore provides the scalability and high-availability of the virtual cloud infrastructure so that the web application itself is scaled and fail-safe, and uses the character of each cloud provider.

How a cloud computing infrastructure is used almost to perfection shows Netflix impressively.

Source: Adrian Cockcroft

Netflix the supreme example

Netflix is the world’s largest cloud service by far. The video streaming service has become responsible for a third of all Internet traffic during peak periods. This user requests must be answered, of course, performant and at any time. Since its launch in 2009 Netflix sets on cloud technologies and has shifted its complete technology stack including the resulting infrastructure to the cloud of the Amazon Web Services in November 2012. Here about 1,000 virtual Linux-based Tomcat Java server and NGINX web server are running. There are also other services such as Amazon Simple Storage Service (S3) and the NoSQL database Cassandra in conjunction with memcached and a distributed memory object caching.

However, this is only one side of the coin. More important is the use of multiple Availability Zones in the Amazon Cloud. Netflix uses a total of three Availability Zones to increase the availability and speed of the own service. Occurs a problem in an Availability Zone, the architecture of the Netflix application is designed that the service can continue to run through the other two. Here Netflix has not relied on the pure marketing promises from Amazon, but developed with the Chaos Gorilla its own software that is testing the stability of the virtual servers Amazon Elastic Compute Cloud (EC2). In short, the failure of a complete EC2 Region or Availability Zone is simulated to ensure that the Netflix service continues to function in an emergency. One of the biggest challenges is in the fact that in the event of an error in an Amazon region, the Domain Name System (DNS) is automatically reconfigured so that Netflix customers do not notice the failure. The different DNS providers APIs make this task not easier. In addition, most have been developed that the settings have to be done manually, which does not make it easier to automate this.

Bottom line, it is to say that Netflix plans ahead for the error case and does not rely on the cloud. Because sometimes something goes wrong in the cloud, as in any ordinary data center. You only need to be prepared for it. Who is more interested in what Netflix makes to reach this state should read “Netflix: The Chaos Monkey and the Simian Army – The model for a good cloud system architecture” (only in German).

Simplicity counts

Maybe I’m asking too much. Finally, cloud computing is a relatively new concept. Nevertheless, Netflix shows impressively that it works. However, when you consider what huge efforts Netflix makes to be successful in the cloud, you just have to say that cloud computing is not simple, and a cloud infrastructure, no matter at which provider, needs to be built with the corresponding architecture. This means, conversely, that the use of the cloud must be more simply in order to achieve the promised cost advantages. Because if one uses cloud computing the right way, it is necessarily not cheaper. In addition to savings in infrastructure costs which are always reckoned up, the other costs as may for the staff with the appropriate skills and the costs for the development of scalable and fault-tolerant applications in the cloud should never be neglected.

The positive sign is that I see first startups on the horizon, who take care of this problem and have set the simple demand of finished cloud resources to their task, without worrying about scalability and high-availability as a user.

Correctly, we name the Amazon Web Services (AWS) as an infrastructure-as-a-service (IaaS). AWS Elastic Beanstalk splits the stock, whether the service should be counted as a platform-as-a-service (PaaS). Anyway, AWS provides various PaaS functionality in its cloud portfolio for some time and extends it now with AWS OpsWorks (still in beta).

What is AWS OpsWorks?

AWS OpsWorks is a solution for the flexible and automated application management. It addresses IT administrators and DevOps developers, who can use it to manage the complete lifecycle of an application, including resource provisioning, configuration management, software updates, monitoring and access control. AWS OpsWorks can be used for free. Costs emerge for the deployed virtual AWS infrastructure resources.

OpsWorks allows you to create a logical architecture, the provisioning of the required resources based on the architecture and providing the application and the necessary software packages for a specific configuration. OpsWorks then cares about the operation of the application and supports the life cycle including autoscaling and software updates.

AWS OpsWorks details

AWS OpsWorks supports different application architectures and works with any software whose installation is script-based. Based on the Chef framework you can use your own ready recipes or those from the community. An event-based configuration system helps during the application lifecycle management. These include customizable deployments, rollbacks, patch management, auto-scaling and auto healing. With that an update can be rolled out just by updating a single configuration file. Moreover OpsWorks has the ability to host AWS instances based on a precisely self specified configuration. This also includes the scale of an application based on the application load, or a time-based auto scaling as well as monitoring the application and the replacement of faulty instances.

With OpsWorks applications can be build in so-called “Layers”. A Layer defines how a set of together managed resources are configured. An example could be a web layer. This includes EC2 instances, EBS volumes including a RAID configuration and mount points and Elastic IP addresses. In addition for each layer, a software configuration can be created. This includes installation scripts and steps for initialization. Is an instance added to a layer, OpsWorks ensures that it will receive the corresponding configurations. OpsWorks provides pre-defined layers of technologies such as Ruby, PHP, HAProxy, Memcached and MySQL. These can be customized and extended.

Technology from Germany

OpsWorks was invented in Germany and is based on the technology Scalarium of the Berlin company Peritor. Scalarium was bought in 2012 by Amazon.

Comment

Indeed, AWS OpsWorks is not a concrete PaaS offering. This is due to the building blocks philosophy of the Amazon Web Services. This means that the offered services will be made available as granular as possible. The customer then has the option to integrate the services for its use case and how it needs them. For that, of course, a lot of personal contribution and knowledge is required, which for the infrastructure of a typical PaaS is not required. However, AWS OpsWorks closes in terms of convenience the gap to the PaaS market and offers more and more PaaS functionality in the Amazon Cloud.

About one thing a customer should be aware of. And that applies not only to AWS OpsWorks but for the use of each AWS service. The lock-in in the AWS infrastructure becomes bigger and bigger with each service Amazon is releasing. This need not be a bad thing. A lock-in is necessarily anything negative and may even be beneficial, on the contrary, as long as the own needs are met, and not too large compromises have to be made by the customer himself.

As a customer you just have to keep this in mind before the way into the AWS cloud, as well as in any other cloud, and consider possible exit strategies or multi-cloud approaches.