devopsy.kinsta.cloud

Author: contributor

The WhiteBox PaaS

One of my favourite blog posts about PaaS is James Urquhart’s ‘Is your PaaS composable or contextual? (Hint: the answer matters)’. In the post, James distinguishes two different types of PaaS: Contextual and Composable. He additionally implied a third type of PaaS (though he categorized it as “Composable”):

“Perhaps most importantly, however, there are open source “build” tool chains being deployed directly to infrastructure services that exhibit a purely composable approach toward delivering and operating applications. Combining GitHub with Jenkins with Gradle with AWS CloudFormation and Autoscaling and so on gives a fully automated, flexible “platform” for application development and operations — everything you want from a PaaS. The catch, of course, is that you’ll need to assemble and maintain that tool chain over time (rather than letting the PaaS vendor do it for you).”

The Whitebox PaaS:

When we started VisualOps, at first we didn’t realize that we were building a new type of PaaS or rather a customizable PaaS, this was partly due to our DevOps background. As James pointed out, the value of a classic “Contextual” PaaS can be achieved by using the DevOps tool chain. There is more transparency and control implied by ‘customizable’ over ‘composable’ as all aspects of the environment are within your control. Each building block’s entire make-up is determined by you rather than merely arranged. The Blackbox PaaS removes this ability to define your own rules.

Though currently this category of tool chain is mostly homegrown, the key point here is that PaaS does not have to be a Blackbox. A Whitebox PaaS exposes 100% native interface of the underlying infrastructure, giving ultimate control and transparency. Combining Infrastructure-as-Code and Configuration Management capability as a quick and easy way to build, automate and orchestrate applications. Compare the Whitebox PaaS with the Contextual PaaS and the advantage is clearly that the Whitebox PaaS poses no pre-determined constraints on the application, and as such your apps will be general-purpose and lock-in free.

Benefits:

A key benefit of this approach is that the Whitebox PaaS is capable of both deploying and managing itself. With aWhitebox PaaS service it is possible that the customer can click to deploy a private clone, and no management effort is required since the clone is supervised by the “origin”. This removes the “operation immaturity” stated by John E Vincent in his blog:

“To be clear while I feel that most organizations aren’t ready for the operational challenges of maintaining a PaaS, the job is made harder by the PaaS software. In both cases, the operational maturity of the products themselves simply isn’t there.”

A further value is that in the WhiteboxPaaS is not th eapplication runtime. Instead,your code will run in standalone infrastructures (VMs), and PaaS only needs to help automate and orchestrate the application. Thus, even if the PaaS is down, your application will still run un-impacted. This entirely side-steps the issue of ” their downtime [being] your downtime”, as well as the security concerns raised by the multi-tenancy of the public PaaS.

Objections:

There may be some concerns regarding the learning curve necessary and intrinsic complexity of the WhiteboxPaaS as it requires your involvement with the application setup and the system architecture. It is true that it is by no means the easiest option. However if you are looking from a business minded perspective, having this knowledge will give you a great competitive advantage. If you don’t know how to do this you may lose the opportunity to build a better, faster and more robust application. Moreover, if people use PaaS to achieve “NoOps”, then it would appear that the real meaning of ‘undifferentiated heavy lifting’ is the day-to-day operations necessary to keep your application running, rather than the knowledge it was built upon. In this context using a WhiteboxPaaS absolves you of all heavy lifting, yet still leaves you with the opportunity and ability to make improvements, it is ‘customizable’.

This is not to say that PaaS must always be Whitebox. James put it well: “it’s not an either/or choice, much like stability and resiliency”. Different types of PaaS serve different markets and different purposes. From our experience, we have seen some customers begin using a Blackbox PaaS such as Heroku and grow rapidly with it until they reach a point where they want or even need something more flexible and powerful, they then choose to migrate to AWS+Whitebox PaaS such as VisualOps. This progression allows you to concentrate your time and efforts wholly into your business itself at the beginning, then upgrade to a more proficient and flexible platform as your business grows.

About the Author
Peng Zhao is the Founder and CEO of VisualOps. Previously, he initiated and led the IaaS projects for China Mobile as well as being both a manager and developer in a various companies, including Reuters and Platform Computing. He holds a MsC. from Univerisity College Dublin. His twitter handle is @gnepzhao

July 25, 2014
How to Find Your Continuous Delivery Rhythm
This article is a part of a series of pieces on digital innovation, accelerating change and the rise of the coded business from innovators in the Chef community. In this article we present an interview with Jez Humble, Principal Consultant, ThoughtWorks, on digital innovation.

Focusing on speed and scale allows you to respond more rapidly to weak signals in the market, and to arbitrage those opportunities quickly. This is different from the way it used to be. In the past, we’d only respond to the strong signals in the marketplace. But now, with the lower cost of investment in product development, and the resulting optionality in that process, we can service subtle market signals effectively.

Here’s an example of this. A company noticed that when people searched for bird-cages online, very few entries came up. So, to fill the void, the company began making bird-cages. And now this business has created a new revenue stream selling bird-cages. We’re also learning that the way we service customer demand – in all its varieties – is part of the product development process. This comes with the emergence of user-experience design. And it shows that marketing, as well as technology, is an essential part of product development today. Zappos is a great case study that illustrates my point. Many companies try to minimize the time spent on customer support calls. Zappos spent a maximum amount of time on customer calls every day. And, by deeply engaging with the customer, they learn about the customer.

Code is really the key to exploring and exploiting new opportunities in an inexpensive and scalable way. And here, we have to give credit to Toyota, which has been using Lean to show us how to re-tool on the fly in response to customer demand. As a result, software is now following automobile manufacturing.

A major part of all this is continuous delivery of code, which, from my perspective, is fundamentally about reducing the transaction cost of putting out incremental changes. And I want to emphasize the importance of incremental changes and small batches; continuous delivery of code really can’t be effective if it’s one-piece flow.

Think about it this way. You don’t buy eggs at the supermarket once a year. And you don’t buy an egg as a replacement every single time you use one. No, you buy eggs on an ongoing basis in small batches. This is the kind of rhythm that powers our ability to move rapidly when there’s a weak signal in the marketplace. It’s the kind of rhythm that powers our ability to change code based on customer demand. And it’s the kind of rhythm that powers our ability to compete effectively – and with a decided advantage.

Netflix, Etsy, Amazon, Google and Facebook are five of the best at this. And I also like the way the British government’s digital service has been re-tooled and re-built with Lean, customer experience, and continuous delivery principles in mind. The government site is, without question, all about customer demand and customer service, and it has saved citizens a lot of money as well. The take-away here is that software companies shouldn’t be thinking narrowly about software; instead, they should be thinking about how their software can better serve customers. To do that, the entire business has to be run differently and more effectively. And, again, technology people – as well as product marketing people, financial people and governance people – all have to join in and help make it happen.

There are three practices of continuous delivery that can help you create the most efficient path from hypothesis to continuous feedback:
- Comprehensive configuration management
- Continuous integration
- Comprehensive automation of build, test, deploy, and infrastructure management
A new kind of “MVP”

One of the key ideas that the Lean startup movement has popularized is the minimum viable product (MVP), which is defined as the least possible amount of work you can do to test your business hypothesis.

Of course, people in manufacturing have been producing minimum viable products for decades – they’re called prototypes. I like the MVP because you’re not betting the company, or spending big wads of cash.

Another key Lean concept is validated learning; here, you gather actionable metrics based on real usage of your product, without asking people. To do this, however, you’ll need to be able to answer questions like:
- Did the changes we made to the product improve signup, retention, revenue? Or is it time to pivot?
- Which version of our new feature came out better when we did A/B testing?
- All our system metrics look okay, but a user reports that our site isn’t working. Are we down?
- Which features of our product are generating the most revenue?
These questions should be answerable by looking at a dashboard, and the information should be completely auditable. But this kind of learning is only possible if metrics are built into the “hypotheses” that are being tested. Once you have an idea for a minimum viable product, you need to start delivering software. The first step is analysis. My view is that you need to do just enough analysis up-front, and this approach needs to continue throughout the lifecycle of the project, with the emphasis on creating very small, incremental stories.

Doing less and learning more

Let’s say you’re working on a hotel booking site, and you want to add a feature to allow people to choose whether they want breakfast. Don’t create this feature for all hotels, or for all partner sites. Instead, start with a “hypothesis” that allows you to add that feature for a single hotel, with no configuration options, and get feedback for that possibility before you proceed further.

Do less, so that you can focus your efforts on learning from your users.

If you want to increase your release frequency, it’s essential to decouple your deployments from the act of taking a feature live. Feature toggles (also known as bits or switches) help you control who can see which features. This setup also allows you to release new versions of revised software that include partially complete features, containing perhaps a story or two of work, but nothing you’d want the general public using.

In addition to enabling incremental delivery of functionality, feature toggles let you turn off a problematic feature when a release goes wrong, as an alternative to rolling back your deployment.

The bottom line is that continuous delivery like this liberates us by reducing the cost and risk of releasing software, and by powering much-needed innovation at the same time.

Jez Humble is a principal consultant with ThoughtWorks and co-author of “Continuous Delivery” and “Lean Enterprise.” He began his IT career in 2000. Over the past 14 years, he has been a developer, system administrator, trainer, consultant, manager and speaker. He has worked with a variety of platforms and technologies, consulting for non-profits, telecoms, financial services and on-line retail companies. Since 2004, he has worked for ThoughtWorks and ThoughtWorks Studios in Beijing, Bangalore, London and San Francisco. He holds a BA in Physics and Philosophy from Oxford University and an MMus in Ethnomusicology from the School of Oriental and African Studies, University of London.
July 21, 2014
5 Secrets of Enterprise DevOps

There is still much debate surrounding the merits of Enterprise DevOps, some say that DevOps is great for the highly scalable startups but not feasible for the enterprise, while others say that DevOps is mandatory for a company’s survival. When enterprises evaluate the potential impact of DevOps adoption, they should consider some key points:

1. Enterprise DevOps Adoption: One Bite at a Time

How do you make sure your developers get instant feedback? How can you go back and forth between versions? How do you integrate your entire CI/CD pipeline? While CI/CD for dummies is a good place to start, the biggest problem is how quickly you will get bogged down by the details. Whether you participating in the NASA challenge to find all asteroid threats to the human population and save the planet, or you are at an enterprise figuring out the DevOps strategy – first things first – define the problem and break it down into actionable chunks which may be done in parallel or sequentially.

When an enterprise is trying to tackle the DevOps challenge, the common scenario is that lots of people will have lots of interpretations on how and what it means to implement DevOps methodologies. It’s easy for projects to get stalled in the initial planning stages. The only way to take on this challenge is to break it down into smaller workstreams, for example, by defining the workflows in terms of infrastructure automation, build & test automation and configuration management – and deciding which technologies are the best fit to solve the specific challenges in each stream. So, basically, how do you eat an elephant? A spoonful at a time.

2. Dead in the water without on-demand cloud capacity

The limited enterprise data center infrastructure simply cannot keep pace with agile teams that need to be able to spin up multiple parallel environments with a click of a button or an API call without getting the message “ran out of capacity”. This issue becomes even more crucial when the project cycle peaks as a new application or updates need to be deployed in no time. To maintain agility in enterprise IT, enterprises must forever break free from capacity constraints, including compute and storage resources. Without a doubt the public cloud is a great fit – you must be able to use AWS and Google Cloud on-demand. To build a massive software lab entirely on premises, knowing fully well the bursty nature of the workloads, is downright foolish. If you want production on VMware and test environments in AWS, you need to ensure high fidelity environments to have real confidence in the test results. The environments must be exact replicas – identical VMs and identical networking in the data center and the cloud. The cloud gives you the capacity but how can you make the temporary test environment identical to production? Today it is indeed possible to clone your IT infrastructure in the cloud at the push of a button.

3. Death by Scripting for Complex Multi-tier Environments

Continuous integration and deployment are great methods increasing effectiveness and efficiencies. However in a multi-tier environment with complex networking elements, the overhead associated with the use of manual scripting to provision the relevant resources (multiple VMs, networking, storage), configure them and deploy all the components of an application each time you need a new test environment is very high. In addition, in today’s highly dynamic environment, scripts become outdated frequently, increasing the pain factor. Design for simplicity and scale: easily repeatable deployments, being able to snapshot and rollback to earlier versions are all requirements that must be carefully considered and met. For example, what if Jenkins could use a single API call to spin up multiple clones of your entire environment in the cloud, run all your tests in parallel, automatically release resources when completed and snapshot the environment in case of errors? Simplifying the automation and designing for complexity is a key requirement for enterprises.

4. Destroying team silos is easier said than done

One of the greatest enterprise DevOps challenges is to make the operations team fully integrated with the dev team and be able to plan and execute despite plenty of unexpected events. True integration of the development and operations teams cannot be stressed enough. For example, the ops team must be part of the SCRUM process. Creating a DevOps team is a start, but creating that DevOps team does not actually bring dev and ops together. Barriers between teams need to come down over time – the different teams need to cooperate and collaborate towards a larger shared vision.

5.Managing infrastructure as code is do-able and totally worth the effort

Delivering on the promise of infrastructure as code does not have to be back breaking. Minimizing delivery cycles including creating just-in-time environments becomes a matter of an API call, hours become minutes. A wide variety of modern technologies are at your fingertips to help you achieve your mission. The most common scenario we see today may be the modern startup where its R&D organization was built with the DevOps notion from the get-go – but that doesn’t mean Enterprises will miss the bus. The enterprises that are adopting modern DevOps methodologies are doing so quickly, without a rip-n-replace of their entire infrastructure. For example, Ram Akuka, Director of DevOps at Deutsche Telekom shared their Enterprise DevOps journey describing how they used VMware, AWS, Chef, Jenkins and Ravello to set up a fully integrated CI/CD pipeline that accelerated their software delivery cycle like never before.

About the Author

Shruti Bhat, Director product marketing at Ravello Systems, the industry’s leading nested virtualization and software-defined networking SaaS. Prior to Ravello, Shruti was a virtualization junkie at VMware, where she managed the software-defined storage product line. She combines her MBA at UCLA Anderson with a bachelor’s in computer science engineering and has previously led R&D teams at IBM and HP as well as immersed herself in start-ups.

July 21, 2014
The evolution of built-in DevOps features in cloud platforms

These days DevOps is being widely adopted by many IT organizations. Such IT organizations become more agile and reliable, deploying code more frequently with fewer bugs and failures. DevOps helps to get better IT performance and build additional competitive advantages, and companies with high-performing IT organizations are twice as likely to exceed their profitability, market share and productivity goals.

The adoption of DevOps is being driven by factors such as agile development methodology, significantly increased rate of production releases, wide choice of public and private cloud platforms, and a wide range of tools for data center automation and configuration management.

Today there are many different automation tools on the market that are used by DevOps teams for provisioning, orchestration and configuration management (Puppet, Chef, CFengine, bcfg2, Vagrant, Fai, Kickstart, Preseed, Cobbler), for build and deployment automation (Jenkins, Maven, Ant, Cruisecontrol, Capistrano), for infrastructure monitoring (Zabbix, Nagios) and application performance measurement (NewRelic, AppDynamics, DripStat).

However IT organizations still struggle with assisting both developers and administrators that prioritize two completely different goals – speed of application development and feature completion versus production stability and uptime. Automation tools vendors promote their products to solve the challenge of DevOps teams, but still very often fail to face the complexity of workflows for operations engineers, or application releases and deployment speeds desired by developers.

Another issue is that IT organizations with application release and deployment issues usually use some kind of automation, but they want to have more flexibility to manage their automation without the need to invoke everything manually at the command-line. Ideally, this automation should be available for developers in their development environments to give developers more control of the environment and understanding of the infrastructure usage.

These issues have driven the evolution of DevOps tools. Today, cloud platform vendors consolidate and integrate automation and management tools directly into their cloud platforms. As a result, IT organizations can get better automation features in the same turnkey cloud platform. We can claim that PaaS solutions will become the next generation of DevOps tools. Cloud platforms have already removed the need to worry about many aspects of provisioning and configuration management of virtual machines/containers. These cloud platforms solve it in a very efficient way, because they have more control of resources and events, they manage the whole cluster of resources and take into account different metrics and status indicators at the same time. As a result, these platforms provide significantly better density of resource, better utilization, smart distribution of the load across the cluster, automation of new release deployments, automation of scalability and maintenance, out-of-the-box high availability and fault tolerance features.

In fact, many IT organizations use automation tools such as Puppet and Chef to solve the challenges of template management, updating middleware stacks, application configuration management and zero-downtime deployment of new releases. However, the latest cloud solutions include more “native cloud” features designed to solve the same tasks. There are many examples of this trend for cloud platforms to evolve in this new, DevOps, direction, providing native automation features in popular cloud platforms.

Let’s take one of the visionaries in the cloud computing industry – Amazon Web Services. One of their cloud services, CloudFormation (http://aws.amazon.com/cloudformation/) allows developers and administrators to create and manage resources, middleware stacks and application templates. It helps to manage configurations and updates of already provisioned resources and applications. Literally, it‘s designed to solve the same tasks as Puppet and Chef. You can find many threaded discussions related to the comparison of CloudFormation vs Puppet/Chef. OpsWorks (http://aws.amazon.com/opsworks/) is another service for application management that simplifies application deployment and lifecycle management. It helps to define application topology, specification of package installations and software and resource configurations. In addition, this service includes automation for scaling based on time or load and allows scripting of these tasks.

Another good example of DevOps evolution is the new cloud services released by Google Cloud Platform. Recently this public cloud platform released several different features that help to solve similar tasks to those mentioned above – Replica Pool (https://developers.google.com/compute/docs/replica-pool/), Startup Scripts https://developers.google.com/compute/docs/howtos/startupscript and Cloud Deployment Manager https://developers.google.com/deployment-manager/. These natively integrated cloud tools provide the ability to create and manage sets of virtual machines (VMs) from common templates, resize, update, or delete them, define different configuration attributes such as base image, attached disk details, attached networking objects and scripts to be executed after the boot, install new software and updates, define environment/OS variables persistently available to VMs whenever it starts. In addition it provides the ability to easily declare, deploy, and maintain complex applications using a simple template mechanism. It provisions, scales, and monitors VMs and applications. Moreover, it can perform regular health checking and can restart or re-build sets of VMs that fail to respond appropriately. Recently announced Cloud Debugger and Cloud Trace (http://googlecloudplatform.blogspot.com/2014/06/enabling-developers-to-tame-production-systems-in-the-cloud.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+ClPlBl+%28Cloud+Platform+Blog%29) allow developers simply setting a watchpoint on a line of code and to get a snapshot of all the local variables, parameters, instance variables and a full stack trace. It helps quickly identify and fix performance bottlenecks and enables engineers to compare performance from release to release with a detailed report. It works with zero setup uptime and no complex configuration, and is suitable for use in production. The tools described above cover a large breadth of DevOps tasks.

Docker (http://www.docker.com/) is another good example of a tightly integrated cloud automation mechanism and a further example of DevOps evolution. The promise and focus of this automation solution are to remove complexity of configuration and deployment into different environments. Many cloud vendors have announced integration with Docker. Many observers believe that Docker is still at an early stage and not yet production ready, but the product has generated lots of industry buzz and the technology seems to be significant.

In addition, there is something even bigger in the DevOps evolution – the open initiative for unification of cloud automation as Topology and Orchestration Specification for Cloud Applications (TOSCA) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=tosca. The goal of TOSCA is to enhance the portability of cloud applications and services, enabling the interoperable description of cloud services and relationships between parts of cloud services and operational behaviors. Examples are template configuration and provisioning, application deployment, software patches and updates, application scaling and maintenance, etc. In other words, it drives a unified standard for independent cloud platform vendors or cloud hosting service providers. As a result, it should simplify the work and tasks of DevOps teams by creating a vendor-neutral ecosystem enabling portable deployment to any compliant cloud platforms, smoother migration of existing applications to the cloud and the ability to build and run multi-cloud provider applications.

In conclusion, the future will bring more cloud native absorption of different automation features for DevOps needs. The evolution of cloud platforms in the DevOps direction is extremely beneficial for IT organizations because they do not need to manage and learn different tools and approaches for automation. This unneeded complexity will be replaced by seamless integration of different automation features inside the same cloud platform. It means in the near future very popular DevOps tools like Puppet and Chef will compete with built-in functionalities of cloud platforms.

However, during the evolution period, choosing the right cloud platform is critical. It should allow IT organizations to use multiple approaches – the old legacy automation methods and the new native features to give the maximum flexibility from built-in automation and an already collected knowledge base. Flexibility of choice is the key point in the DevOps evolution for IT organizations – the ability to use both worlds at the same time: the old automation tools and the next generation features of cloud platforms.

In addition, it makes sense to mention the importance of seamless integration between PaaS and IaaS for the evolution of DevOps. The public cloud platforms discussed above (AWS and Google Cloud) provide merged solutions today. The integration of both layers is very important for enterprises that heavily use private and hybrid clouds, as it replaces the unneeded maintenance complexity of two different solutions and removes extra overhead on integration of products from different vendors. In other words, merging PaaS and IaaS provides extreme flexibility of automation and ease of use in the same solution. Seamless cloud platforms provide the best combination of the automation features in the same turnkey cloud solution that help to drive innovation and maintain legacy apps.

The next generation of cloud platforms will establish a win-win relationship between the dev and ops departments, and when the outcome of dev and ops interactions is a win-win, IT organization performance wins as well.

About the Author

Ruslan Synyntsky, is founder and CTO of Jelastic. With over 15 years in the IT industry, Ruslan is an expert in large-scale distributed Java applications and enterprise platforms. Before founding Jelastic, he led engineering teams a and at the Space Agency, Ukrainet iQueLab, SolovatSoft, Datamesh.

July 18, 2014