Building apps for the hybrid cloud is different than building apps to run purely on dedicated gear. This is why my team and I created the Five Pillars of Cloudiness at Rackspace, and I was happy to present them at the Unlocked session this week at OSCON in Portland. Here is a summary of the talk, and you can also check out previous posts on both the DevOps blog and the Rackspace blog for more detailed information on each pillar.
One of the most beneficial things you gain by having a seemingly “unlimited” amount of resources at your disposal in the cloud is the ability to parallelize. As we discussed at OSCON, more is better, but it’s not always the case.
Think about something like moving. If you move your entire house yourself, you know everything is going to be given the same priority and nothing is going to get in your way, but it’s going to take a long time. On the flip side, if you hire movers, you are entrusting they will treat all of your items the same. Multiple people working at the same time speeds up the moving process, but every now and again you both end up at a doorway waiting for one person to pass through. This is an example of deadlock. How do we solve this in the physical world? A small chat or head nod and one person passes and we’re back on track.
Computer software needs that same “chat” or “head nod” as the go ahead, and this is something you need to think about while designing applications. For example, you should consider where the potential is for contestation of resources or whether there is a race condition that has occurred because of a decision you’ve made. Scheduling, TTLs and other software tricks are all ways you can maximize parallelism without compromising productivity.
In the early days of the automobile industry, one person was responsible for the entire work on that vehicle, limited to working on a single car at a time. The assembly line changed all of this. Instead of one person working on the entire car, the components such as the chassis, engine, body and interior were split out and assigned to specialists. This same practice can be applied to hosting architecture.
For our standard three-tier application, instead of having the presentation, application and storage tier on one particular server, developers taking advantage of modular design can split out each tier on its own node. Doing this not only can help you attempt to pinpoint issues when they arise, but it can also open the door for you to take full advantage of our next pillar of cloudiness, the one that gets a lot of people excited about the cloud.
A big myth is that the cloud can scale horizontally out of the box. Unfortunately, this is not quite true—you have to build this functionality into your app. Many people are familiar with vertical scaling, or adding more CPU cores or RAM resources to a server. In the cloud, you can scale vertically with a couple of clicks in our control panel, however, not only will there be a small amount of downtime while your server rebuilds, your node can only get so big. Rather than having one large node, it is better to spread those resources to several smaller nodes, effectively scaling out horizontally.
Using a configuration management tool like Chef or Puppet can help you horizontally scale your application as different monitoring thresholds are achieved. But instead of defaulting to scaling your environment when certain CPU or RAM thresholds are hit, I advise you to take a critical look at what you should monitor. In Margarine, our open-sourced web reader application that we created to help train cloud application design, we found that the number of messages queued was a better metric to trigger another node coming online. Had we looked at CPU utilization, we would have never brought on another node, and our users would have become quite frustrated. What you choose to measure and monitor truly matters.
As opposed to the Waterfall model of development where every requirement is documented up front, the Agile model embraces solving a problem in short sprints of work. This means that there is an organic growth to the software, moving to a cadence between one to four weeks. The Agile model for development has great advantages when it comes to making a cloudy app. You have smaller amounts of work to test and run through Q/A, resulting in a faster deployment to production. Furthermore, you have fewer items and changes that could break in production, making it easier to identify the source of the bug when one does crop up.
Trust is about a bond between you, your customers and all of your users. When this trust is violated, you could see damaging effects to the adoption of your application. Consider the security of all the interfaces on all of the tiers of your application, and use de facto security practices such as:
When it comes to security, you need to look at host-based authentication and user-based authentication. For host-based authentication, adopt normal server hardening steps like authentication keys, turning off challenge-response and even preventing logging into the sever. User-based authentication is difficult and, if it makes sense, consider offloading it to a company like Stormpath. If you have to do this yourself, you may want to consider multi-factor authentication for your users, staying true to tried and battle-tested authentication methodologies.
Want to learn more about the hybrid cloud? Stop by our booth (No. 507 ) in the middle of the OSCON exhibit hall and ask us any questions you may have. While you’re there, play our Unlock the Cloud Game to get a t-shirt. You’ll also have a chance to win a Game of Thrones Sigil pint glass set and to be entered to win the grand prize, a Game of Thrones Stark Infantry Shield.