Blog Archives
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!
When in doubt, blame the cloud
Every time there is a failure for any software that is off-premise, the critics are quick to say “See, I told you the cloud sucks!” I was following some of the discussions about SOA and cloud computing today on eBizQ’s webinars and the statement was made that the cloud adds more silos and more complexity and enterprise software generally sucks. I respectfully disagree with that assertion. I do agree that many companies will build cloud services that do create more silos and do make things more complex, but that is not the fault of the technology. It is the fault of the implementors. A classic cause for this is the notion of porting legacy applications and services that were never built to run outside an organization’s perimeter security. I often call perimeter security a “false sense of security”. My reasoning is IT shops traditionally don’t do a good enough job building application security but they manage to get by (sometimes) by hiding behind their firewalls.
To prevent silos and to prevent complexity, one should be skilled in architecture and know how to properly approach software development. We can argue all day whether enterprise architecture is a good thing or a bad thing, but we should at least take a page out of EA and ask the who, what, when, where, why, and how questions from the business, information, systems, and infrastructure perspectives before we go rushing to into the clouds.
At M-Dot Network where I work, we start with our guiding principles. They are:
- Keep it simple
- Make it configurable
- Make it self monitoring/self healing
- Drive IT costs down
- Security and compliance are of highest priority
So after you answer those six important questions from those four important perspectives, then you apply the guiding principles to the overall design. If your choices of technology keep you from achieving these goals, than either you don’t have the right people designing your systems or you chose the wrong technologies. This is not the fault of the technologies but the fault of the choices that the architects made. So let’s stop blaming the cloud for everything and admit that the real reason why enterprise architecture sucks, is we keep building crappy software.
Cloud Computing: Expert opinions everywhere, but where are the experts?
I have found that with cloud computing there seems to be a ton of “expert” advice but it is not coming from people who are actually building solutions in the cloud. Many giving “expert” advice are seasoned veterans and talented people, but they are simply stating opinions not backed by any facts. Most have simply read about the cloud’s pros and cons, formed their own opinions, and now claim their opinions as facts. Where are all the architects and engineers that have actually designed and implemented real solutions in the cloud? Shouldn’t we be listening to their opinions (and I am not talking about the vendors’ engineers)?
So here are some of the generic statements (aka “facts”) that I see daily:
- Cloud is not secure
- Application XYZ failed therefore the cloud is a failure
- You are crazy if you put mission critical applications in the cloud
I could go on and on but you get the point. So let’s discuss these “facts” one at a time.
Cloud is not secure
This one drives me nuts! I heard a well respected industry analyst at a well respected conference declare “I just don’t understand how you can put customer data in the cloud. When you buy Amazon, you don’t buy security”. I raised my hand and asked, “When you buy a rack of servers from IBM, are you buying security?”. The point is, you don’t buy security, you architect for it. Whether you are using a SaaS, IaaS, or PaaS provider, you must understand what security features are addressed, what isn’t, and what the risks are. Then you must design to mitigate those risks. It is not different than what you should be doing on-premise. Understand your requirements, and build (or buy) the appropriate solution. So to sum it up, the cloud by itself is often not secure enough. You may outsource your infrastructure but don’t outsource your brain. There are still things you must do to secure your systems and services in the cloud.
Application XYZ failed therefore the cloud is a failure
Whether it is GMail, Tmobile losing Sidekick data, Ma.gnolia database crashes, or Coghead going out of business, any failure of an off-premise solution seems to feed the myth cloud computing is too risky. However, we continue to fail miserably each day with our on-premise solutions but we can keep it from the press because it is behind our firewall! In each one of the above mentioned failures, the issue lies with operational issues on the side of the provider and not issues with the cloud infrastructure itself. I would argue that GMail, which is free, is at least as reliable than most corporate Microsoft Exchange implementations (at least for the companies that I have worked for in the past). Also, if you are using SaaS solutions, you should have a mitigation strategy in place for lost data. Outsource the business processes but not your brain! You still need business continuity, disaster recovery, record retention policies, etc. And when did on-premise become so perfect? How many companies do you know keep the lights on by having employees run around with duck tape and bailing wire plugging up the holes in the bottom of the boat. Let’s face it, most failures are due to issues in architecture, design flaws, missed requirements, human error, weak controls, or poor implementations.
You are crazy if you put mission critical applications in the cloud
This one really drives me nuts. The problem here is semantics and we really should be careful what we say. It is one thing to say mission critical apps don’t belong in the public cloud and another to say it doesn’t belong in any cloud (which is how it often gets interpreted). But even the term mission critical means different things to different businesses. Even though you and I might not see Twitter as a mission critical application to our business, it is for others. Some companies exist solely because they leverage Twitter’s APIs to deliver their products and services. Now we all know Twitter’s track record of reliability. But their performance and up-time was failing miserably before they moved to the cloud. It improved once they migrated to Amazon. Twitter’s problem is a flawed architecture, it is not a cloud computing issue. I have written in the past about our secure hybrid cloud solution for processing micro-payments. As a startup, I would argue that I would be crazy not to build this in the cloud. In an era where it is difficult to raise money, my costs would increase ten-fold had I opted for an on-premise solution. I would have to build or lease at least two data-centers and staff them accordingly. Instead I can use a combination of cloud vendors coupled with a sound architecture to secure these transactions and meet all regulatory requirements. If I already had an existing data-center, I would not have been forced to look beyond the opinions of others and try to solve the security and compliance requirements that my business required. I just think that many people’s opinions about the cloud are focused primarily on their specific business models or domains. So what may be true for their world does not necessarily apply across the board. We tend to generalize too much.
Summary
There are many opinions out there about cloud computing and there are many smart people offering them. Unfortunately, many of these these smart people have not rolled up their sleeves and tried to solve real business problems in the cloud (nor do they need to). In my case, as a matter of survival, we had to find out for ourself. By no means, do I consider myself an expert in cloud computing. But I do believe that spending a year actually working on delivering enterprise solutions in the cloud from scratch does entitle me to challenge the opinions that are deemed facts. At the end of the day, it all comes down to knowing your business and technical requirements and applying sound architectural practices to provide a secure and compliant solution, whether it is in the cloud, on-premise, or both.
</rant>
Is social media making us dumber?
I have been a big fan of social media but lately I am starting to think that much of the information we share on the various social software tools are inaccurate, unproven, and nothing more than opinions. The problem is that anybody with a blog, a Twitter account, or a Facebook account can say anything and other people will accept it as the truth. On any given day, you can find content that is nothing more than someone’s bias opinion that is being used as facts to support opinions of others. Here are a few examples just from the last hour:
1. On Premise proves less secure than Cloud
This is simply not a fact. Yes we can find examples where this may be true, but for every case study supporting this argument, there is a case study that supports the opposite opinion.
My take: An application or service is only as secure as the implementation team makes it. I can make a system secure on-premise and off-premise. I can also implement a system with gaping security holes in my own data-center or in the cloud. It is not the infrastructure that provides the security, it is the implementation of the system on the target infrastructure that determines how secure the it is. In other words, it takes people to make systems secure. They must understand the risks and the requirements and apply the appropriate level of security.
2. Any reputable SaaS provider will provide robust PCI compliance as a default feature
What if the SaaS solution has nothing to do with credit card processing? Why would a SaaS provider spend valuable time and money to pass a PCI audit if there is no business justification?
My take: We need to be careful with generalizations. Reputable SaaS providers who need to be PCI compliant should be, but lets not making sweeping generalizations. Does Google Maps need to be PCI compliant? Didn’t think so!
3. Please Don’t Let the Cloud Ruin SaaS (blog post here)
The author equates today’s SaaS solutions on AWS to the old days of distributing software on DVDs thus shifting the responsibility of security to the customer. I have a lot of issues with this assessment. First of all, not all SaaS solutions are deployed on AWS or IaaS (Infrastructure as a Service) platforms. If you do your homework on cloud computing, you will know that IaaS providers can only secure the infrastructure. They do not provide application security because the customer is free to build whatever solution they want. PaaS (Platform as a Service) providers can provide a higher level of security because they are higher up on the stack and have more control over the applications.
My take: We need to understand that the particular use cases that we experience within our business or our domains do not necessarily correlate to all use cases and all domains. The author’s assertions are valid for certain use cases, but they should not be perceived as truths for all SaaS solutions. We need to be careful of generalizations.
Summary
The problem with social media is that our attention to details are now about as long as a 144 character tweet. The above mentioned tweets lead to blog posts that have some valuable insights and data points to consider. But none of them are pure facts. They are opinions based on specific use cases and experiences. However, many consumers of content shared on various social software tools are so swamped with information that they are forming opinions and making decisions based on tweets and generalizations thus adding to the hype, myths, and mass confusion that we encounter daily on various technical topics. So in the spirit of not generalizing, I believe social media can make us smarter due to the collective intelligence of many people (in some instances). But at the same time, it can make us dumber due to the collective opinions of the bias and uninformed.
*** Disclaimer: By no means am I implying that the authors of the above mentioned content are dumb or malicious. My point is that with social media, we must take what we read with a grain of salt. There is always another side of the story.
</rant>
Will the Cloud drive SOA adoption?
I participated in a podcast today on EBizQ with Peter Schooff, managing editor. You can listen to the podcast or simply read the transcript here.
To summarize, I believe that companies with a sound architecture that is loosely couple from both their data layer and their infrastructure are in a great position to take advantage of cloud computing. Companies that are tightly coupled or “hard-wired” to their databases and servers will struggle. In fact, I would argue that tightly coupled architectures are not good candidates for cloud computing. Instead, companies that are “hard-wired” are better off only building brand new applications in the cloud and should not even attempt to move legacy applications off premise.
I also predict that 10 years from now the cloud will be common place for companies of all sizes. The next 2-3 years we will finally start seeing real enterprise success stories, especially in the government sector where the government is driving numerous large scale cloud initiatives. Check out the podcast as I answer five important questions about SOA and the Cloud.
Potential Impacts of Amazon’s Virtual Private Cloud
I usually don’t get involved in vendor discussions. I like to think of myself as vendor agnostic (or some say anti-vendor). But I think today’s announcement of Amazon offering a virtual private cloud (VPC) solution is rather significant for a number of reasons.
1. Clarity of the Private Cloud definition
Chris Hoff’s post sums it up the best:
In one fell swoop, AWS has:
- Legitimized Private Cloud as a reasonable, needed, and prudent step toward Cloud adoption for enterprises,
- Substantiated the value proposition of Private Cloud as a way of removing a barrier to Cloud entry for enterprises, and
- Validated the ultimate vision toward hybrid Clouds and Inter-Cloud
Of course this won’t end the mass confusion over cloud definitions and the arguing over semantics, but it clearly differentiates between on-premise and off-premise. In my opinion, part of the definition of cloud computing is the outsourcing of infrastructure, so I don’t consider on-premise attempts at virtualization to be private clouds. Amazon’s Werner does a good job of outlining the benefits of cloud vs on-premise:
I often get asked to define “The Cloud,” especially because of the many permutations that different vendors use in trying to make their existing businesses look like a cloud offering. I define the cloud by it benefits, as those are very clear. What are called private clouds have little of these benefits and as such, I don’t think of them as true clouds.
The cloud:
- Eliminates Cost. The cloud changes capital expense to variable expense and lowers operating costs. The utility-based pricing model of the cloud combined with its on-demand access to resources eliminates the needs for capital investments in IT Infrastructure. And because resources can be released when no longer needed, effective utilization rises dramatically and our customers see a significant reduction in operational costs.
- Is Elastic. The ready access to vast cloud resources eliminates the need for complex procurement cycles, improving the time-to-market for its users. Many organizations have deployment cycles that are counted in weeks or months, while cloud resources such as Amazon EC2 only take minutes to deploy. The scalability of the cloud no longer forces designers and architects to think in resource-constrained ways and they can now pursue opportunities without having to worry how to grow their infrastructure if their product becomes successful.
- Removes Undifferentiated “Heavy Lifting.”The cloud let its users focus on delivering differentiating business value instead of wasting valuable resources on the undifferentiated heavy lifting that makes up most of IT infrastructure. Over time Amazon has invested over $2B in developing technologies that could deliver security, reliability and performance at tremendous scale and at low cost. Our teams have created a culture of operational excellence that power some of the world’s largest distributed systems. All of this expertise is instantly available to customers through the AWS services.
Source: Amazon Web Services Blog
2. Simplifies hybrid cloud architectures
This is where I get excited. I have talked at great length about a hybrid cloud solution that my company is building. Since Amazon only had a public cloud offering prior to today, I had the added complexity of integrating two cloud vendors to make up our hybrid solution. This meant I needed to manage two separate vendors with two distinct SLAs and introduced some potential latency issues communicating between the two vendors’ platforms. Assuming that our testing of the beta goes well, Amazon’s VPC simplifies our architecture and makes it more manageable. I also feel that the risk of my private cloud vendor going out of business or getting bought by a competitor has been greatly reduced. Another advantage is that my engineers already have experience with Amazon EC2 which greatly reduces the learning curve on the private cloud. I am a believer in the KISS (keep it simple stupid) theory.
3. Threatens the livelihood of private cloud vendors
Dave Rosenberg of CNet tweeted “AMZN’s new private cloud service just put a half-dozen startups out of business.” He may be right. Before this announcement, private cloud providers were not directly competing with Amazon. Now they are. There is one caveat though. For Amazon’s VPC to replace private cloud vendors, they must allow for access for auditing purposes. In my case, the whole purpose of the private cloud is to put critical data on computing resources that are not shared so that audits can be performed. So Amazon’s VPC solution is not complete if they still refuse audits to be performed in this environment.
When I was evaluating private cloud vendors, I was alarmed by how expensive they were. On the surface, Amazon’s VPC looks significantly cheaper than many of the vendors I researched, although I confess that I have not done a deep analysis on this yet.
Summary
It will be interesting to see how this announcement impacts the competition amongst the cloud vendors. I assure you that many vendors will try to change the public perception of Werner’s definition of private cloud to one that closely resembles their approach. It will also be interesting to see the results of the first few beta tests of the VPC solution. My team will be kicking the tires on it. If VPC turns out to be everything Amazon promises it to be and they do allow for auditing of VPC images, this will be an absolute game changer for the industry and cloud computing. My 2 cents!
