SOA & Cloud Computing: Beyond the Myths
I had the pleasure of presenting at Utah St.’s 26th Annual IT Seminar yesterday. The conference was planned and run by the students. I was impressed both by the work the students did and the support and guidance given by Utah St. Very impressive! I must also add that the snow covered mountains of Logan, Utah was one of the most beautiful sights I have ever seen.
My presentation was focused on what is SOA and Cloud Computing and how can we get past all the hype and all the myths and actually deliver real business value. After all, if you are not doing for the business, why bother?
There are two very extreme views out there. One view is that the there is nothing new with SOA and Cloud Computing and it is nothing more than hype. I am so tired of hearing “we have been doing this for years”. My response is we have been doing phones for years, you can’t tell me there is nothing new happening with phones these days. The other view is that SOA & Cloud Computing are silver bullets. Simply outsource the infrastructure to the cloud and life is grand. WRONG!
The answer lies somewhere between those two views and really depends on these factors: time, money, architecture, people, and change. How well you balance those factors greatly influence the results you will have.
My key point is that when things fail, it is caused by people not by the technology. It all comes down to architecture. One must fully understand the risks, design for them, and deliver business value in the process. Check out the slides for more information.
Cloud architectures: Part 1 – Reliability and Scalability
My team and I have been architecting an enterprise platform for over a year now. Our platform is an aggregation model that connects multiple channel partners to multiple retail partners and is 100% cloud based. I wish I could share some of our architectural drawings with you, but since I can’t I have created some very generalized diagrams that allow me to discuss architecting for the cloud without giving away our secret sauce.
When building an enterprise platform that connects many companies together, we must be able to guarantee high availability and scalability while protecting against lost data. In this post I will discuss one approach to meeting these requirements. It is important to note that for this post I am focusing on a 100% cloud solution built on Amazon’s AWS platform, an IaaS (infrastructure as a service) solution.
The following image shows a logical representation of our approach. Keep in mind that to physically implement this approach, there is a significant amount of technology that is required which is not represented in this diagram.
 |
| From Cloud Computing |
You can see at the top of the diagram, both web users and systems can trigger a request to the platform through elastic IPs. What is cool about elastic IPs is that you can create an IP that your channel partner’s system knows, but internally your IPs are changing regularly as you scale up and down your servers or perform maintenance. This allows you to make changes to internal IPs and images without requiring changes on your channel partners systems.
CloudWatch – Auto-scaling layer
CloudWatch is a relatively new web service from Amazon which allows you to set thresholds so that the platform can automatically scale up and down as needed. CloudWatch can auto-scale both your load balancers and your EC2 images. For each farm of EC2 images, you can set the minimum and maximum number of images you want CloudWatch to control and set thresholds based on a variety of metrics that trigger the scaling events.
Elastic Load Balancing – Load balancing layer
Elastic load balancing is a software based load balancing solution. This is another web service that Amazon provides to simplify the building and management of infrastructure. Where CloudWatch manages how many instances your platform needs at any given time, ELB is responsible for distributing the traffic in a manner that optimizes the resources that are up and running. ELB can detect when an EC2 image is starting to degrade in performance and reroute traffic to better performing images. This can be done within a zone or across zones. This is extremely important because Amazon has had an occasional outage within a zone but has never had all zones down at a single time. In fact, since these zones are located in different physical locations, it is extremely unlikely, barring some major catastrophic event that hits multiple areas of the country, that all zones will be down at any one time. That is why it is a best practice to distribute EC2 images across multiple zones and use the ELBs to reroute traffic in the case of a zone outage. Think of each zone as a virtual data center, without the cost of real estate, hardware, utilities, assets, and large staffs to manage it.
Server Farms – Web, Application, and Database layers
It is not a mandatory requirement to physically separate your web, application, and database logic onto separate EC2 instances. It really depends on things like budget, volume, required performance, memory requirements, and many other factors. We chose to break these out into separate layers because of the enormous volumes we anticipate, the strain we put on system memory, and some of our location specific data requirements. Within each layer (if you can afford it), I recommend having redundant servers in each zone. That way if any zone is down, there is still a fail-over solution within each zone. Note the difference between an Amazon zone and an Amazon region. Amazon regions are US-East, US-West, and Europe. Within each region there are multiple zones. There is no additional cost to route traffic across multiple zones within a region. There is a cost of routing traffic across regions.
Backup/Recovery – Leveraging S3
S3 is Amazon’s Simple Storage Service which automatically distributes data across multiple zones within a region for you. A simple S3 web service call automatically performs real time distribution of data across multiple zones thus eliminating the need for those clunky, expensive, and highly ineffective tape backups that we have been doing for years and years. S3 is a critical piece of the architecture. Not only is is good for backing up content, but you can deploy a sound backup/restore strategy on it too. The snapshot feature allows for frequent snapshots of database slaves as well as Apache and web logs. If there ever is a need to recover from a glitch, we can easily pull the last good snapshot off of S3 and restore it.
Summary
I glossed over these points at a high level. Logically this appears very simple but there is a lot of work required to build an architecture like this. However, this architecture can be built in a fraction of the time and for a fraction of the cost that an on-premise version of this architecture would take. The combination of the distributed capabilities of S3 coupled with a multi zone approach for deploying EC2 images, enables us to build a highly reliable and scalable platform. In addition, this concept of virtual data-centers allows us to provide our customers and channel partners with the confidence that we can execute an effective business continuity and disaster recovery plan.
From time to time I will write additional posts about building cloud architectures on Amazon. Look for my next post to discuss data services and hybrid clouds. As always, questions and feedback are welcome!
Protected: 2D Bar Codes
Observations of a burned out corporate soldier turned entrepreneur
As I reflect on the year 2009, my first full year at my new startup, I thought I would share my observations as I look back at the challenges that I used to deal with throughout my long corporate career.
 |
| From Enterprise Initiatives |
In November of 2008, I joined a startup called M-Dot Network as CTO and employee #1. I had spent the first 23 years of my professional career working for medium sized corporations with IT shops in the 100-300 person range (Note: I enjoyed working at all of these companies and learned valuable lessons). I started out as a programmer working on mainframe systems and eventually followed the market and developed on Unix and Microsoft based client server environments. In the late 90’s there was a manager position available in my group. I applied for it only because I was tired of working for managers who knew nothing about technology. What I found out is that I knew nothing about management and I really sucked at it. Being a competitive guy and one who does not like to suck at anything, I worked real hard at improving my management skills and eventually my leadership skills. Over time I worked my way up into senior IT leadership roles where my last corporate role was chief architect. Along this journey from programmer to manager to C-level, I learned a lot about people, cultures, and organizations. I also learned that many of the frustrations of corporate America are not unique to any one company or culture but are almost epidemic in our society. Here are some of my observations:
- As companies grow, the employees get further detached from the overall vision and mission. The overall mission becomes lost at the lower levels of an organization if the company does not continuously communicate the mission, actually deliver on the mission (not just words), and reward people for contributing to the mission.
- Layers are only good for onions. When you run out of fingers on one hand counting the reporting layers between the workers and the IT top dog, the company’s ability to innovate becomes crippled. I have seen a medium sized IT shop with 8 layers. A small group of corporate soldiers did a ton of work and the middle 6 layers spend a lot of time communicating up to the top layer what these people were doing. To make matters worse, they typically reported what the top wanted to hear because the non-worker bees had to justify their existence. How productive was that?
- The reward structure in most companies are the root cause of all evil. Companies tend reward the people who break shit and then fix it instead of rewarding people who deploy stuff that works. Working hard tends to pay better than working smart. It is all about perception which is the direct result of putting managers in charge who know nothing about the technologies that they manage.
- Companies tend to get too inbred. The downside of longevity is that people start to feel too secure in their jobs and feel like their job is a privilege, not something they must earn each day. When a company becomes too inbred, adopting technologies or methodologies that require organization change become extremely challenging. This point was one of my main reasons for exiting the corporate world. In an inbred culture, everybody knows what the problems are but nobody wants to lift a finger to help change it. That is what happens when people think of their job as a privilege instead of commitment to the people who deposit money into their bank account every two weeks.
- You are who you hire. “A” players hire “A” players, but “C” players hire “C” players. Put one “C” player in a leadership role for a couple of years and that area will be littered with “C” players over time. Some of them will get promoted into leadership roles and mediocrity will spread like a virus. This is one of the biggest culture killers. If enough “C” players get in power your “A” players leave.
- IT tends to forget why they are being paid. The whole business-IT alignment issue is just mind boggling to me. Growing up in a family owned business there was never any confusion that the goal was to provide value and satisfaction to the customer so that the business would prosper. It was easy to see who the customer was. In corporate IT, we tend to forget who the customer is. I have even seen some people who don’t think they have any customers! It shouldn’t be that hard. There are external customers (buyers of products and services) and internal customers (people who get external customers). At the end of the day IT must enable both of those groups. I have seen way too many IT resources spending way more energy serving everyone except the customers who pay the bills and the people who sell to them.
- Silos represent lack of overall leadership. Silos are corporate killers. Silos create broad inefficiencies from a technology standpoint, a business process standpoint, a customer service standpoint, an organizational agility standpoint, and so forth and so on. Silos are often the result of a company growing rapidly with no strategy or roadmap of what the company wants to be when it grows up. How many times have you seen a good company grow like crazy for a number of years and then hit a wall? When the dust clears from several years of rapid growth, many companies find themselves riddled with inefficiencies and sky rocketing expenses caused by organizational silos. Mini cultures start forming within these silos and even within departments. I have seen turf wars between groups within IT. Forget about business-IT alignment, we often need IT-IT alignment. This is a direct result of senior level management not keeping their eye on the ball. No matter how fast a company is growing, they should have a growth strategy and a plan to prevent “hitting the wall”. Growth is not only generated from products and services, it is driven by people.
- Many people hate their jobs but will never leave. This is like cancer. I have seen good hard working people turn into unproductive and even destructive employees. Sometimes this is caused by lack of opportunity, lack of acknowledgment of accomplishments, or just a direct result of the above mentioned bullets. I always go back to our family business where my dad had a small pharmacy with about 3 employees. If somebody hated their job, their performance sucked, thus causing a poor customer experience. That person would be gone in a heart beat. In the corporate world, these individuals can last forever and some even get rewarded for it!
- Politics get in the way of sound business decisions. It amazes me how political some organizations have become. My first thoughts are always about how we can increase revenue, decrease expenses, and help our customers. Unfortunately, many people let topics like career aspirations, vendor favoritism, and even religion factor into their decision making process.
I could go on but for those current and former corporate soldiers out there, you get the point. Now that I am in startup, I am completely free of all this nonsense. At the same time, I want to make sure as we build this company from 10 to say 100 people, that we don’t make the mistakes of the past and create another one of these political, silo-based, innovation-starved organizations. Life in this startup has been so energizing to me for the following reasons.
- Everything is earned. We raise money one angel investor at a time. We cannot fail. When I get in front of highly successful business people who are trusting part of their retirement in our hands, I have an obligation to do everything in my power to give those people a return on their investment. If they had not taken a chance on us, I would be back in a cube or corner office dealing with the pain and politics of corporate America. These investors have set me free and created a better quality of life for me and my family. We owe them our best effort every day!
- Business and IT is aligned at the hip – We cannot survive without business and IT alignment. IT builds the services and does everything in its power to provide the business with the tools it needs to sell and raise money. That is just good business. When the organization is less than 10 people that is a no-brainer. The challenge is to not lose sight of that by the time the company hits 100 people.
- No time for politics. In our environment, it is a first market mover opportunity. There are many players competing for this new piece of pie and the first one to grab the lion’s share will be very successful. The others may perish. So there is not time for power plays, position jockeying, brown nosing and all those games. If we don’t deliver we simply will cease to exist.
- Perform or leave. When you only have a handful of employees, everybody must bring their “A” game. In a 200 person IT shop, you can carry some dead weight. When the number of projects and clients exceeds the number of people in your organization, everybody must deliver every day.
- Everyone wins and loses together. In the corporate world, you can always tell when your company has a good quarter because the executives and top sales guys are driving yet another new Mercedes to work. Everyone else is still struggling to put food on the table. In most startups, the early employees usually sacrifice significant amount of salary in exchange for equity. This is great for two reasons. First, it keeps the burn rate down but more importantly, everybody is highly motivated because so much is at stake financially for everybody. If we fail, we all lose lots of money that we could have been earning in salary. But if we win, we can make way more money than we ever could have made as law abiding corporate soldiers.
- Agile is required. There are no wars about whether agile makes sense or not in the startup environment. Our motto is JEJIT – Just enough, just in time. When you take money from angel investors and VCs, they want results. When your paycheck is coming from 40-50 people that you know by name, you tend to not see your job as a privilege. You must show incremental progress in short increments so you can continue to raise money to allow you to progress towards that multi-year roadmap. Be quick or be dead!
Conclusion
I think my early days of working in my dad’s pharmacy trained me to be very customer focused and results oriented. Then I entered the corporate world. In the early days while I was in development, I was so energized by learning new technologies that many of the issues in the corporate world were foreign to me. When I entered management, I started to realize that corporations broke many rules of good business practices. The higher up I got, the more apparent it was and the more frustrating it became. Even though I was getting paid good money, I was actually happier when I was in my own little world solving problems with code. All along, I was trying to apply the mindset of an entrepreneur in organizations that were not able or willing to accept those principles. It is hard to create change when status quo is rewarded. So I bailed after 23 years, with no job. Now, 18 months later, the same philosophies that I tried as a law abiding corporate soldier are welcomed and necessary in the daily survival game in the world of a startup. My biggest challenge (besides making sure we succeed) is figuring out how to grow this company and keep the entrepreneurial spirit.
We have a joke around here….”When we have to hire a VP of Human Resources, it is time to sell”. It is a joke, but it just might be reality. When we have to dedicate people to managing people instead of delivering products and services, it is the first sign that the company is on the path to becoming corporate. When the business and IT leaders start talking about aligning, it is time for the next startup!
Windows 7 Upgrade – ATI Driver issue
I just spent the better half of the day upgrading my son’s Dell 1721 laptop from Vista to Windows 7. I have done my share of Linux installs and upgrades on all kinds of hardware configurations but this was one of the toughest I have ever been through. Once I resolved it, the fix is rather easy, but finding the fix was a challenge. I am thankful for the many people who post useful information in forums so that people like me can resolve our problems. Hopefully this post will help some folks and save them a great deal of time and frustration.
The Problem
When upgrading from Vista to Windows 7, I received an error message that I needed to update my driver for my ATI AHCI Raid controller. So I went to the device manager and clicked on upgrade driver. Windows told me that it was up to date already. Keep in mind that the install process would run for 15-20 minutes each time before it would tell me what the issue was (grrrrr). I had a number of other issues reported initially which required me to uninstall certain software modules. Each time I complied, the install process would run for another 15-20 minutes to tell me about the next problem. When I finally got to the driver problem, I was stuck. No matter what I tried I could not update the driver. I finally found a discussion thread in a forum that led me to the solution. It is a long back and forth thread so I will spare you the details, instead I will show you how to resolve the issue below.
The Solution
The way to resolve the driver issue is to manually copy the new driver over the old driver in the appropriate folder and DO NOT REBOOT! Rebooting was the culprit which for some reason would bring back the old .sys file. So here are the steps.
- Download the RAID Driver here. Make sure you download the RAID driver and not one of the other drivers.
- Run the setup program for the RAID driver (9-12_win7_32-64_raid.exe)
- Locate the driver (.sys file) by going here ->C:\ATI\Support\9-12_vista32-64_raid\Packages\Drivers\SBDrv\SB7xx\RAID\LH
- Copy the driver (ahcix86s.sys)
- Go to C:\windows\system32\drivers and backup the driver ahcix86s.sys (likely has a 2007 date)
- Paste new driver (ahcix86s) into this folder (should now have a 2009 date)
- DO NOT REBOOT
- Run Windows 7 installer
That’s it! It took me several hours to find all of this information and successfully implement this solution. I hope this helps somebody and saves several hours.
One last note: For all you Microsoft fanboys who bash Linux, this Windows 7 upgrade was a complete pain in the ass and was much harder than most Linux installs I have ever worked on. I even had to recover a Mac once and found it easier to resolve than this. Anyhow, good luck to those who are reading this and looking for a solution!
UPDATE:
After following the steps above, the Windows 7 upgrade went through its process. It requires a reboot several times. For some reason I kept getting an error that it could not find a rebootable partition. So every time it rebooted I had to press F12 and tell it to boot from the RAID drive. Then it would continue the upgrade process. I do not know if this issue is related to any of the steps above.
UPDATE 2:
The “no rebootable partition” issue was caused by the fact that I left a thumb drive in a USB port which I used to back up some of my files. It was not related to any of the above mentioned steps!
Cloud Security Alliance issues v2.1 of Cloud Computing Best Practices
The Cloud Security Alliance (CSA) issued the second version of its “Guidance for Critical Areas of Focus in Cloud Computing”, now available on the Cloud Security Alliance website. You can find the press release here. I read the first version front to back a few times and found it helpful in my quest to build M-Dot Network’s architecture which is 100% in the cloud. What I like most about this body of work is that it was put together by practitioners from many different perspectives: security, infrastructure, application development, etc, but more importantly, the work was performed by volunteers and not funded by vendors.
Like my colleagues that I work with in the CAEAP (Center for the Advancement of the Enterprise Architecture Profession), my CSA colleagues are all seasoned veterans who share a common goal of improving the IT profession.
The CSA Guide v2.1 is a must read for any IT professional who is researching or actively working on cloud computing initiatives. This guide helps practitioners cut through the hype and FUD and focus on the real issues and opportunities that the cloud presents. Download it, read it, educate yourself and share it with others.
Lessons learned from a year in the Clouds
This month marks the first anniversary of when my startup, M-Dot Network, started building our enterprise solution on Amazon’s cloud computing platform. So as I reflect on a year that went by in a blur, I decided to share my thoughts on what I learned about cloud computing.
Low startup costs
One of the first things we had to do after we defined our business architecture, was to create a demo that our CEO could take with him on the road. My engineer, who had never used Amazon AWS before, created an account using the company credit card, and quickly built a working model of how our system would work. He built both a web site and WAP interface that allowed a consumer to select online coupons and built a prototype of a store system that redeemed the coupon by calling our redemption engine in the cloud. The process took about 2 weeks and our IT costs for the month (excluding labor) was $86. Our CEO could now go on the road and show potential customers and investors just how our system worked (or would work in the future). The wow factor of walking into a client site, having them pull up their cell phone or their browser and perform an end-to-end shopping experience that utilized the cloud live was huge. And we did it for under $100!!! In fact, the only hardware we have purchased to date is our netbooks.
Optimal R&D environment
In my post called Building Better Software in the Cloud I discussed how we were able to fire up many different configurations to prove out our architecture. In my previous jobs, we would normally either be told what hardware our target application would run on or we would have to take a best guess very early on because of the long procurement cycles that often took several months. Then when the hardware came it we hoped like hell that our projections were accurate. In the world of cloud computing, we were able to experiment with many different CPU and memory configurations and simply only paid for the time we spent using those virtual machines. After performing numerous tests with numerous configurations, we knew exactly what “hardware” we needed to get the job done. There is tremendous value in proving out your design before you buy your target architecture. For one, if the project ever got canned, you are not stuck with hardware. Second, you no longer need to guess what you need and risk buying too little or too much computing resources. The “Try before you buy” model is a key differentiator in my book!
Ability to perform huge performance tests
One of the most impressive experiences I had in my first year in the cloud was the massive performance test we performed with our testing as a service partner, SOASTA. As documented in a SOASTA press release, we were able to prove that our architecture could easily process one million concurrent transactions in 1/10th of a second! To perform this test, SOASTA fired up over 700 virtual servers to run their software and we fired up over 50. After the test we both quickly tore these servers down to “shut the meter off”. A test like this is not even feasible in the on-premise world! This test was executed in one day. That means both companies fired up a combined 800+ servers, ran the test, and decommissioned the servers all in a day’s work. We only paid for the time we used the servers. You simply just cannot do that on premise. What this means is that in the cloud, you have the ability to stress test your system and discover and fix your bottlenecks when running worst case scenarios before you go into production.
Speed to market
This part is every system administrator and DBA’s nightmare. We built an entire platform without having a single DBA or system administrator on staff. We invested some time upfront to create standard AMIs (Amazon Machine Images) that contained all of the appropriate security controls and configurations for the OS (Linux), the database (MySQL) and the app server (Apache). Once the standard AMIs were built, deploying more was as simple as a few clicks of a mouse and a 2-3 minute wait. We no longer had to go through long, painful procurement cycles. We no longer had to argue with the system administers or DBAs about the priority of setting up our server or our database. We no longer had to bother anybody about taking snapshots of production data for use in our test environment. I could go on and on but I think you get the point. Things that used to take weeks or months in our previous jobs now take minutes. This means we spend more time actually building business functionality and less time managing the infrastructure. Which leads to the next point.
Focus on the business needs
The beauty of building our architecture on Amazon is that they make it real easy to deploy and manage compute resources. We are able to build in auto-scaling capabilities, we can easily leverage S3 to replicate our data across multiple virtual data-centers, and quickly deploy a simple backup strategy consisting of snapshots and data replication (no tape!). What that means is we can easily build a self monitoring, self-healing system that requires minimal human resources to deploy and monitor, so our people can focus on building features for our customers. Amazon has recently released RDS which abstracts a lot of the core database administration functions for MySQL. We have been testing it recently and found some huge time savings with it. We are also testing the queuing service (SQS) which can save us an incredible amount of development. With SQS, we can get guaranteed delivery of all of our messages/transactions without having to build out the complex logic required to perform that function. Once again, Amazon provides the plumbing required to run systems and we focus on our business functionality.
Build secure systems
I have said it before and I’ll say it again, I can build highly secure systems on Amazon’s cloud platform. Security is something you build not something you buy. Many people underestimate the security and regulatory controls that are in place on the Amazon platform. I described it in detail in this post. As a startup, there is no way I would be able to build a solution even remotely close to being as secure with an on-premise solution than what I can build in the cloud. The reason is simple. I would never have enough cash to hire enough security professionals, build enough data centers, and develop all the proper controls. Even if I went the hosted route, I could never afford the costs of deploying across multiple data centers because of the lack of the “pay-as-you-go” model with hosted solutions.
Build high performance systems
When we first started this journey, our biggest concern was performance. We knew we could build things cheaper and faster but we did not know if the cloud would provide the level of performance our systems required. As I mentioned previously, we are able to process over a million transactions concurrently with sub second response time. It took a ton of sophisticated engineering to get there, but we proved it could be done. What is even better is that if we need to handle more transactions, we can just fire up more AMIs. We can scale this almost infinitely.
Amazon owns this space
Last but not least, Amazon is by far the clear leader in this space. Not everybody who has built systems in the cloud have enjoyed as much success as we have. Some companies like Rackspace have had severe outages. Others like Coghead have gone out of business. Then there are others who have lost customer data. The list goes on. Amazon has not had any of those issues. In addition, they are the thought leaders in this space and are providing many highly valuable services such as S3, SQS, RDS, and others that further abstract the infrastructure layer so that their customers (like me) can focus on their business. I was also fortunate enough to attend Amazon’s AWS Partner training and got some insights into future features and functionality (under NDA). I can tell you that building apps and services on AWS is going to continue to get easier and more cost effective as time goes on. Amazon has a great strategy of releasing services quickly with just enough functionality. Then they follow it up with many subsequent releases that increase the robustness of those services.
Summary
I had studied cloud computing for over a year before I had the opportunity to work on it. I was fully aware of the pros and cons and went into this journey with high expectations. A year later I can tell you that what we are able to do in the cloud far exceeded my high expectations. We have built a high speed transaction processing engine that is highly secure, meets all of our required regulatory demands, absolutely screams from a performance perspective, and allows us to get stuff done in days what used to take months. I actually feel sorry for all of the colleagues I left behind in the corporate world, well, most of them anyways!
The most amazing thing to me is that the cloud is still in its infancy which means that 2-3 years from now the capabilities will far exceed what we have today. I can see a day where an entire web site architecture can be a service that is provided by Amazon. Today I have to plan out a web server layer, a db server layer, a caching layer, etc. Tomorrow I might just access an AMI that represents that entire architecture.
So these are my lessons learned after one year. I don’t really have any “what not to do lessons” because we did our homework, we started with architecture first, we built in the appropriate level of security, and we didn’t have unrealistic expectations coming in. Oh, I do have one. Don’t listen to people who say that the cloud is not ready for prime time!
What the masses are missing about the Cloud – Part 2
In part 1 of this four part series I highlighted the top 4 negative comments that I commonly hear about the cloud:
- The cloud is insecure
- Cloud computing is immature
- Cloud is nothing new. We have been doing this for years.
- Cloud computing is not really cheaper
I addressed security in part 1. In this post I’ll discuss maturity.
Speaking of technology that is not mature, I am writing this post at 30,000 feet as I fly home from Boston. Sure WiFi, especially WiFi from planes is far from perfect and mature, but we still all use it. The “cloud is immature” statement is the same excuse we heard when PCs first came out and when the Internet starting becoming a viable option for businesses.
So we have a camp that says “the cloud is nothing new” and another camp that says it is immature. Which is it? In my opinion, it is somewhere in between. Yes, the concepts of external hosting has been around for a while, but is that really the same thing as cloud computing? Could you get a virtual server with tons of CPU and memory for 80 cents an hour 10 years ago? Didn’t think so. Today’s version of cloud computing is so much further advanced than yesterday’s hosting model. So much more of the infrastructure and administration duties have been abstracted. The price point has made it feasible and reasonable for companies like mine to never have to buy servers again. The auto-scaling capabilities allow companies to react to spikes in traffic (both up and down) proactively without needing to procure additional resources.
Are there a lot more technological advancements required before there will be mass adoption of the cloud. You bet? There is a lot of room for improvement in areas like standards, security, and even performance. But like any other technology, it is the job of the buyer (or leaser) to understand the risks and to mitigate them. Architecting for the cloud today requires that one understands the strengths and the limitations of the cloud. There is no magic here. It all boils down to architecture. Wherever there are gaps it is up to the architects to address them. For example, if your business requirements call for PCI compliance don’t expect the cloud to provide that for you out of the box. You have to design for that (I have discussed a few options in the past).
I just attended the New England Venture Summit where several startups pitched their business models to a dozen or so venture capitalists. You can’t tell any of those entrepreneurs that the cloud is too immature to build a company on. In the technology category, every company was leveraging the cloud. All of us have some form of SaaS solution and most of us are delivering that SaaS solution on top of Amazon (IaaS), Google (PaaS), or some other cloud vendor. All of these companies are deploying quickly and burning very little capital in the process. These companies are not just building pretty websites. I saw examples of serious data mining applications, high speed transaction processing, testing as a service, and others.
My thoughts
As with any technology that is in the hype phase, there is a lot of resistance to change. The companies who architect their enterprise correctly for the cloud have an opportunity to reap the following benefits:
- Substantial reduction of Capex
- Speed to market
- Better disaster recovery & business continuity
- Ability to forecast IT costs
- Better scalability
So maybe the cloud is not as mature as some would like, but can we really afford to continue spending investor dollars for physical servers that are usually not optimally utilized? Can we continue to slow down the business with long procurement cycles? Can we continue to not have a robust disaster recovery plan because the CFO refuses to write that huge check?
For those companies concerned with the maturity of the cloud, why not test the waters with something that is not mission critical? Here are some good non-mission critical use cases:
- R&D or proof of concept work – Why purchase hardware for a new initiative before you prove out your design? Use the cloud to stress test your app. Use the different size servers available to you. Find the bottlenecks. All this can be done for just a few bucks. Tear it down when you are done.
- Adhoc analysis – Do you have a lot of data to crunch through? Fire up some servers and do the processing in the cloud. Get your answers and tear down the environment when you are done.
- Data Backups - Take some non-critical data and replicate it in the cloud. Say goodbye to tape drives and the companies that ship this data to hardened locations.
The reason why I encourage those who are pessimistic about the cloud to try one of these low risk scenarios is once they see how easy it is, how productive they can be, and how inexpensive the project will be, then maybe they will see the value and investigate further. A lot of people just say no to the cloud without ever kicking the tires on it. When somebody who works at a place where it takes several weeks or months to procure a server right clicks on an virtual image, tells the system to fire up five new servers, and the servers are ready in five minutes (including database and application servers), they just may change their view on the cloud. I’m just saying!
What the masses are missing about the Cloud – Part 1
Every day I read numerous articles that are negative towards cloud computing . I can sum them up with the following bullets:
- The cloud is insecure
- Cloud computing is immature
- Cloud is nothing new. We have been doing this for years.
- Cloud computing is not really cheaper
Most of the people who continue to doubt the value of the cloud have not actually rolled up their sleeves and proved any of their theories. I typically try to ignore this talk but I can usually only bite my tongue for so long. Then I post a long rant (like this one) and I am good for another month.
So how about we hear from somebody who is actually building an entire company in the cloud opposed to hearing from IT purists with no hands-on experience with the cloud. So before I address each of the above mentioned claims, I ask that you suspend judgment and consider the following:
The cloud is insecure
Oh really! I would argue that a properly architected solution on Amazon would be far more secure than the majority of on-premise deployments today. First of all, here is what you get with Amazon AWS before you start adding your own processes and solutions:
- Physical Security – Years of experience building large scale data center. Non-descript facilities, military grade perimeter berms, strict access controls, 3+ levels of two-factor authorization, and much more
- EC2 (virtual server) Security – SSH logins, all access logged, AWS Admins can’t login, customer generated key pairs, mandatory inbound firewall, signed API calls, customer instance isolation, and much more.
- Disk level security – Logically isolated virtual disk that is wiped clean after use, no access to raw devices, disk management to prevent disk access from other images, and much more.
- Network level security – DDoS mitigation, IP spoofing prohibited at host OS level, port scanning neutralized (inbound ports blocked by default), packet sniffing protected at hypervisor level
- Compliance - SAS-70, SOX, and customer examples of HIPAA
 |
| From Cloud Computing |
Source: Amazon
That is what you get “out of the box”. Then if you architect it properly, you also get:
- Fully redundant and replicated data including image and database snapshots across multiple virtual datacenters, each with an individual SLA of 99.995.
- SSL encryption of intransit API calls
- Data encryption, cryptographic file systems
- Virtual private clouds with private IP ranges, subnets, encrypted VPNs,
- Multi-factor authentication and much more
Is it perfect? No. Do all cloud vendors have a robust security strategy like Amazon? No. But if your take what Amazon gives you and add some additional levels of security within your applications, I would argue that you can build solutions with far better security than most companies deploy today. In addition, you don’t need an army of staffers to focus on all of the above mentioned security features, your cloud vendor does that and they keep the technologies current so you can focus on your customers.
My thoughts
As a startup, I can tell you that I could never raise enough money and afford enough time to build a robust enough security solution to even compete with what I have on Amazon right now. More importantly, our core competency is not security so why would I want to reinvent the wheel and invest huge amounts of money to reproduce what is already available to me at a fraction of the cost?
I think that established companies might want to start thinking like a startup. Just because you can afford to continue buying physical machines and investing in physical data centers doesn’t mean that it is a good plan. Times are changing. IT needs to deliver faster than ever before. The more time we spend addressing our customers and arming our sales staff with tools and information, the better our company will be. At a minimum, we owe it to our company, our shareholders, and ourselves to at least do some due diligence on security in the cloud and not just listen to self proclaimed experts who are simply resistant to change and spout FUD with no basis to back up their claims. Most of the negativity I hear about the cloud is the same nonsense we heard when companies started to turn to the Internet as a new platform for delivering value. Let’s think about the bigger picture. Business 101. Focus on your core competencies, off load everything else.
Reaping the benefits of Data Services
I have written in the past about my company’s need to be able to implement our database layer in a variety of locations and in a variety of structures. Here are a few of the reasons why:
- Real time failover – we have our data replicated to multiple virtual data centers
- Multi-channel partners – we are an aggregator of digital incentives across multiple industries with multiple data structures
- Geographical requirements – certain customers and countries restrict moving data off of their premises.
- Regulatory – PCI, SOX, HIPAA and others require us to meet specific data requirements
- Security – We don’t allow anyone direct access to our databases. Internal structures are hidden from everyone in the ecosystem
The following presentation which I discussed at eBizQ’s webinar on the Convergence of Cloud Computing and SOA discusses M-Dot Network’s aggregation model and on slide 6 it shows an example of how we use a data services layer to meet the above mentioned requirements.
We recently had to rapidly build a web user interface to assist in the demonstration of our end to end solution from the creation of coupons down to the automatic redemption at the point-of-sale. One of my engineers has been focusing on building RESTful services using Django for the sake of ease of implementation and speed. What this enabled us to do is to outsource the development of the user interface to a team of experts in web development. The beauty of it is that they had no prior knowledge of our business and data structures and didn’t really need to know. We hid the complexity of our underlying data structures and granted them access to the data through the service calls. The services were very easy to understand and use as well as configure. During our testing we uncovered a few minor issues in the data that the web guys were displaying on the screen. With a simple change to some of the values they were passing in the URI, we were able to fix the bugs without ever touching SQL or the database itself.
So what did we learn from this exercise? By abstracting the data layer and creating configurable services as access points to the data, teams can quickly implement solutions in a controlled and standardized manner. So here are some thoughts about the benefits of this type of approach:
- Agile – teams can move quick due to the simplicity of the data access and the fact that they don’t need extensive knowledge of the underlying data. Also, the upper layers of the stack are loosely coupled from the data. If a certain customer requires a slightly different data structure or has location specific requirements, the implementation is hidden from upper layers (presentation, business processes, rules, etc.). Therefore, you make the changes in the data layer and/or in the data services and you are done.
- Cost effective – The further up the stack you go the cheaper the resources. Build the base with your experts and outsource the presentation layer. Makes for very cost effective user interfaces and makes change requests at the presentation layer much more feasible.
- Quality – Testing of CRUD functions are easier and should provide better results. Access to the data layer is controlled through these data services which tend to improve data quality due to single point of updates. Once those services are tested thoroughly, they only need to be regression tested if they remain unchanged for the next deployment.
There are many more benefits I could speak to but you get the point. I do want to point out that data services should be used when and where it makes sense. We have two major domains within our architecture. The first is a high speed, high volume transaction processing engine. We have stress tested the transaction processing engine up to a million concurrent transactions. Our response time is required to be in milliseconds. With these high speed performance requirements, we would not dream of using web services and data layers because the overhead would slow us down too much. For this we use old fashion tricks like caching, compression, and eliminating disk IO. But for the user facing systems like our B2B and B2C portals, RESTful services and data service layers make all of the sense in the world!