The 51 page eBook, introduces and outlines the concept of modern application architecture that is “cloud aware,” and enables organizations to ship better, faster and more robust software.
The book is organized into three parts, The Rise of Cloud-Native, Changes Needed and the Migration Cookbook. The first section of the book explains the “why” of migrating to cloud-native architectures, as well as the unique characteristics of cloud-native application architectures. The section introduces new concepts and buzzwords like the Twelve-Factor App and Microservices utilizing Containerization, which we have covered in in detail on our own blog.
The “Changes Needed” section of the book discussed the required cultural, organizational and technical changes required to adopt this new methodology of application architecture. The section introduces the importance of moving from siloed IT resources to a DevOps methodology to enhance communication and collaboration through software development, quality assurance, database administration, system administration, IT operations, release management and project management. Stine also explains the importance of embracing a Continuous Delivery model to ship better software more efficiently.
With the Canadian dollar on the decline and the high cost of popular US-based PaaS providers like Heroku, we are finding that more and more Canadian based SaaS providers, agency development shops and IT departments are on the lookout for an alternative solution that provide similar functionality at a lower cost.
You do not have to look very far. It is no secret that we are huge fans of our partner, Cloud 66. Cloud 66 provides full stack container management-as-a-service. What does this mean? Cloud 66 is DevOps-as-a-service and it provides you with everything you need to deploy, scale and protect your applications on a number of approved public clouds, including Cloud-A.
Yesterday, the Linux Foundation announced the newly formed Cloud Native Computing Foundation – a Linux foundation collaborative project backed by industry giants like AT&T, Box, Cisco, Docker and many more. In addition to this announcement, Google has also announced that it has donated it’s Kubernetes container technology to the foundation, just days after announcing its support for the OpenStack foundation for the sake of advancing container technology. As advocates and users of container based technology and cloud native applications, we at Cloud-A are really excited about this string of announcements and the affect it will have on the adoption of modern, container based, cloud aware technology.
There is a huge buzz around Docker these days, and we are huge fans of it at Cloud-A. Docker is an essential component of our Continuous Integration System and it also runs Cloud-A’s management plane. We get lots of questions from customers about how they can run their containers on Cloud-A. Here is a look at how you can use Cloud 66 DevOps-as-a-service to deploy, scale and product your doctor container on Cloud-A.
At the forefront of modern application architecture is a concept known as DevOps, or the marrying of development and operations into one harmonious, collaborative and cooperative effort, all with the goal of rapidly producing software and improving operations performance.
As a result of the trend toward DevOps within organizations, a market of DevOps tools have emerged that enable automation and faster, higher quality software. Here is a list of DevOps tools that our partners, our customers and even the Cloud-A team use on a daily basis to deliver software.
Chef is a systems and cloud infrastructure framework that automates the building, deploying, and management of infrastructure via short, repeatable scripts called “recipes.” But the real power of Chef may be in its use of pluggable configuration modules (aka cookbooks), nearly 2,000 of which are available via the Chef community. High-profile Chef user Facebook recently open-sourced some of its own Chef cookbooks, including its Taste Tester testing framework and Grocery Delivery, which watches a source code repo, such as Git, and keeps the local Chef server in sync.
The University of Pennsylvania’s Wharton School is a Chef user as well. “Chef automates complex tasks that are otherwise time- and resource-intensive, but more importantly it allows us to focus our efforts on innovating and improving the quality of our services,” says Sanjay Modi, a technical director at the school, in a case study on Chef’s website. “It also opens the door to more collaboration and efficiency across the organization.” Chef has been used by Wharton to automate configuration management for Amazon EC2 resources, Linux nodes, and local virtual machines.
Docker brings portability to applications via its containerization technology, wherein applications run in self-contained units that can be moved across platforms. It consists of Docker Engine, which is a lightweight runtime and packaging tool, and Docker Hub, a cloud service for application-sharing and workflow automation.
“Docker has been a vital part of Yelp’s next-generation testing and service management infrastructure,” says Sam Eaton, engineering director at Yelp, in a case study on the Docker website. “Isolation of dependencies and rapid spin up of containers has allowed us to shorten development cycles and increase testing speed by more than four times.”
Puppet Enterprise, from Puppet Labs, offers data center orchestration by automating configuration and management of machines and software. Version 3.7, the latest release, features Puppet Apps, purpose-built applications for IT automation, including Node Manager, for managing large numbers of systems that are changed often. An open source version of Puppet is also available.
Stanford University uses the open source version of Puppet “to bridge the gap between the software development that we need to do to create new kinds of digital library services and the systems administration that we need to do to keep those services running in a high-performant, secure way,” says Stanford’s Bess Sadler, in a video testimonial on Puppet’s website. Developers have become more involved in systems administration, while systems admins have deepened their involvement in software development, enabling quicker development of applications, she says.
Ansible is an open source IT configuration management, deployment, and orchestration tool. It is unique from other management tools in many respects, aiming to provide large productivity gains to a wide variety of automation challenges. While Ansible provides more productive drop-in replacements for many core capabilities in other automation solutions, it also seeks to solve other major unsolved IT challenges. These include clear orchestration of complex multitier workflows and cleanly unifying OS configuration and application software deployment under a single banner. Hootsuite uses Ansible to build any server from scratch and repeat this as many times as they want within their infrastructure and are looking to expand use for app deployment. “Ops and Devs both feel safer, literally. Before they were always worried about ‘what if the server dies’, but not any more after all servers are properly ‘Ansiblized’.” says Beier Cai, Director of Technology at HootSuite Media, Inc.
One DevOps tool that is close to our hearts at Cloud-A is docrane – and that is because it is our project! Docrane is an open source Docker container manager that relies on etcd to provide relevant configuration details. The program watches for changes in configuration and automatically stops, removes, recreates and starts your Docker containers, enabling more seamless continuous integration. “Docrane has allowed us to significantly accelerate and improve our Continuous Integration process at Cloud-A. When managing an increasingly large network of OpenStack nodes, having the ability to ensure that new versions are deployed quickly and reliably is key,” says Jacob Godin, CTO of Cloud-A.
Over the next several weeks, we will be highlighting effective use cases of these DevOps tools with Cloud-A including tutorials in an effort to educate and promote modern application architecture, faster time to market and better quality software.
We come across clients all the time who have their applications built on Heroku, but have requirements from their clients to have their data resident in Canada. This was one of the drivers for creating the relationship we have with Cloud66. Here is a guide for migrating from Heroku to Cloud66 + Cloud-A.
About migrating from Heroku
Migrating your application from Heroku to Cloud 66 involves deploying your code, importing your data and redirecting your traffic to the new endpoint.
What server size do I need?
Using Heroku, you can choose between 1X (512 MB), 2X (1 GB) and PX (6 GB) server sizes. This makes it easy to calculate your server requirements, and we recommend that you use similar server resources when deploying your stack with Cloud 66. We also recommend that you have a separate server for your database in production environments.
Once your code is deployed, it’s time to migrate your data across. The process differs for PostgreSQL and MySQL databases:
From your Heroku toolbelt, create a database backup URL by running heroku pgbackups:url. Next, visit your stack detail page and click the Import Heroku data link. Paste the URL provided by the toolbelt into the field, and click Import Heroku data.
Finally, use the command below to import your backup into the database. You can find the generated username, password and database name by visting your stack detail page and clicking into your database server (eg. MySQL server).
$ mysql -u [generated_user_name] -p [generated_password] "[database_name]" < /tmp/backupfile.sql
Once you’re ready to serve traffic from your Cloud 66 stack, you need to redirect your traffic to it. For more information, see Configure your DNS.
Web server and Procfile
By default, Cloud 66 will deploy your stack with Phusion Passenger, but you can also choose acustom web server like Unicorn. You may have a web entry in your Procfile to do this on Heroku. Cloud 66 ignores this entry to avoid compatability issues.
To run a custom web server, we require a custom_web entry. It is important to set this before analyzing your stack, to avoid building the stack with Passenger.
You can also use the Procfile to define other background jobs.
Heroku restarts all dynos at 24 hours of uptime, which may conceal possible memory leaks in your application. When you migrate to Cloud 66, these will become noticeable because we don’t restart your workers (other than during a deployment), so the leak can grow to be bigger. A temporary solution is to re-create the Heroku restart behavior, for example with this script:
for OUTPUT in $(pgrep -f sidekiq); do kill -TERM $OUTPUT; done
This will send a TERM signal to any Sidekiq workers, giving them 10 seconds (by default) to finish gracefully. Any workers that don’t finish within this time period are forcefully terminated and their messages are sent back to Redis for future processing. You can customize this script to fit your needs, and add it to your stack as a shell add-in.
Note that this is a temporary solution, and we recommend that you use a server monitoring solution to identify the source of your leak.
Asset Pipeline Compilation
If you haven’t compiled assets locally, Heroku will attempt to run the assets:precompile task during slug compilation. Cloud 66 allows you to specify whether or not to run this during deployment.
Making your App Canadian Data Resident
Probably the simplest step in the whole process is ensuring that your application is Canadian data resident. You will need to create an account with Cloud-A. Then when you set up your stack on Cloud66 ensure that you select Cloud-A as your cloud provider of choice.
We are happy to announce our partnership with Cloud 66, a leading provider of Devops-as-a-service, giving you everything you need to deploy, scale and protect your applications on Cloud-A in a single tool.
This partnership allows Cloud-A users to deploy and manage their applications more efficiently than ever before, offering one click, automated functionality for managing the lifecycle of your entire stack on Cloud-A which allows developers to do what they do best.
This partnership is part of an ongoing effort to provide Cloud-A users with world class tools to run their workflows on our high performing, secure, Canadian resident cloud servers.
Visit our Cloud 66 solutions page here for more details.