In the cloud,one service model does not fit all
I wrote a post called which cloud service model is right for you a few weeks back. On Monday, 12/12 at our Cloud Camp in Winston-Salem, I will be giving this presentation on cloud service models.
As I mentioned in my previous article, my company uses a combination of all three models. We have a high speed transaction processor and a high volume consumer facing web site on AWS, we are building a few work flow style applications on Force.com, and we leverage many SaaS solutions for our non-mission critical and non-core competency tools.
There is still time to register for the free Cloud Camp if you are in the area on Monday the 12th.
Admins and the cloud: Doomsday or Center Stage?
I will start with the disclaimer that I grew up in the app dev side of the house and was thrust into the DevOps side of the house as a CTO of a startup with limited resources. I know that there are pockets of on-premise admins that absolutely despise and even fear the cloud. But is the sky falling for professionals who have spent 20+ years building and patching servers and managing complex networking architectures? Only if they perceive that it is.
 |
| From Enterprise Initiatives |
Source: http://krishna.org/2012-the-end-of-the-world/
The cloud has thrust the behind the scenes superstars onto center stage because without the expertise of these veterans, the cloud delivered services and applications can quickly become a major fail story. What I find even more fascinating is that many ancient and expensive admin tools are quickly falling out of favor for new open source or SaaS solutions that have been built in recent years and don’t carry all of the baggage of old commercial software. There has been a tremendous amount of innovation in the cloud management space and more is coming!
So let me get this straight. If I am a DevOps kind of guy and someone gives me an opportunity to implement a new infrastructure management strategy using some of the hottest and high in demand technologies in the marketplace while learning new tools and applying my years of experience, I’m thinking this is a great thing! Where do I sign? Of course, for those who hate change, the cloud sucks!
The same applies to security professionals. No longer is security, especially application security, an after thought. Security is the CIOs number one concern with the cloud. This puts the security professionals on center stage as well. I was at the Cloud Security Alliance conference a few weeks back surrounded by many scary looking security folks, you know that look! The message I heard over and over was “don’t fight it, embrace it” and “we must help secure the cloud”. This should be the same mantra for the DevOps folks (they have that look too). They should be saying “don’t fight it, embrace it” and “we must help manage the cloud”.
So is it doom and gloom or does the cloud thrust the back office guys into the spot light where they have always belonged, right along side the developers? Thoughts?
Cloud and on-premise cost comparisons: Apples and Oranges
I have encountered a lot of discussion lately trying to evaluate the costs of both an existing IaaS delivered solution and a proposed PaaS delivered solution to the equivalent cost of building or hosting the same on an existing data center. In every discussion it appears that the cloud is simply more expensive. The problem is we are comparing apples to oranges. What we really need to do is a side by side TCO (total cost of ownership) analysis.
 |
| From Enterprise Initiatives |
Here are the issues I run into when non-cloud folks analyze the costs of on-premise solutions.
- They only count the initial purchase price of the hardware, not the cost to patch, maintain, power, manage, host, etc.
- They assume that if the hardware and/or software is already purchased, it is “free” from here on out
- They don’t account for human labor costs
- They don’t account for the declining value of aging assets
- They don’t account for the intangibles of IaaS (abstraction of data center capabilities) and PaaS (abstraction of development platform and capabilities)
In a nut shell they are simply comparing a one time cost of a server to an hourly cost of a virtual machine that has all of the above mentioned costs baked in. So when one looks at a per user license of a PaaS or SaaS tool, they need to realize that they are getting way more than a license that one is used to getting for commercial software. They are getting all of the benefits of not having to build the infrastructure, provide elasticity, build highly redundant and fault tolerant applications, etc. With a traditional commercial software product, the license (plus 20% annual maintenance) gives you permission to use the software. It does not include the costs of buying redundant servers, managing and patching those servers and software stacks, providing for disaster recovery, etc.
I also hear a lot about how restrictive the platforms are and all of the things that you can’t do on it. What about all of the things you can do on it? If SalesForce.com is built on Force.com and it is used by most of the fortune 100 companies and provides the proper uptime, reliability, autoscaling, security, SLAs, etc., then why is it not a good enough solution for your enterprise? Think about that. Don’t get me wrong, the cloud is not the answer for everything and PaaS has its limitations for applications with extreme processing requirements (IaaS is good for that), but building things yourself on-premise is not cost-effective and one could argue it is not even responsible anymore if the requirements don’t merit it.
And finally the last argument which drives me nuts is this:
” The cloud does not have robust enough development tools, testing tools, debugger, etc.” Neither does the open source stack I use which costs substantially less than commercial software and simply powers most internet apps. Yes the cloud is not as mature as a .Net on-premise computing environment. But is the comparison really about developer preference or is about business drivers? is the most mature and familiar tools always the best tools? Cobol is pretty mature. I don’t see people running to that anymore. To borrow a phrase from the ESPN Football Countdown, “Come on, Man!”
SOA anti-patterns revisited
As I mentioned in a blog post earlier, I am engaging in yet another enterprise wide SOA initiative and would be blogging internally sharing my lessons learned. In the name of reuse (pun intended) I figured I would also post here on my blog. My apologies to all of those fatigued from years of SOA discussions. Here it goes….
SOA Anti-Patterns
This is my first blog post in a series of many about SOA. As some of you may know, this is my third go around with Service Orientation. I have learned a lot of things by failing first and would like to save you all from having to learn the hard way too. That is not to say my previous SOA initiatives were failures. They have their share of success stories. But the road to success was much harder and more costly than it needed to be. With that said, let me share an ancient classic blog post from SOA expert, Steve Jones, written way back in 2006.
There are a few anti-patterns that I want to focus on because I feel they are relevant for our situation.
Anti-pattern: The technology altar
We have had passionate debates on the need to talk to the business about SOA or tie our SOA initiatives to key business objectives. Doing SOA in an IT vacuum results in what I call doing “IT for the sake of IT”. It is important to remember that the reason IT exists is to support and enable the business, period. The business, either directly or indirectly, pays for everything IT does. It is critical that our SOA initiative is attached at the hip with some key business benefits. We all know the IT benefits of SOA: reuse, better integration, reduce maintenance, etc. But how do these IT centric benefits get our product owners excited? They don’t. What product owners want to hear is increased sales, faster customer on-boarding, improved customer satisfaction, etc. SOA can provide all of that if we have a well-defined roadmap of projects that drive business value through the use of service-orientation. Sure we don’t need to ask the business if we should do SOA or not, but how will we fund SOA (the tools, the overhead, the governance, the design time, the people, etc.) if our product owners don’t understand what they get in return?
My recommendation: Make sure your SOA initiative is aligned with key business drivers that are tangible and measurable.
Anti-pattern: A million services in a row
This pattern is a killer and either leads to slow and unusable applications and/or incremental hardware purchases to make up for poor design. What happens here is developers get passionate about services and decide that everything must be deployed as a service. Now I am a big fan of services, but services carry some baggage. First, they take more time to design properly. Second, they can create a hit on the overall performance. Third, they create more demand on stricter governance and oversight. In other words, services are expensive and should only be considered when the consumption of the services merits it. For example, if a service is likely to only be used in one place by one application, why is it a service? Why did we spend the time to build it and the ongoing money to manage and maintain it? Also, if everything is built as a service, there is probably a lot of duplication occurring across development teams. An analogy I like to use is the comedy skit where two guys line up for a fight. The one guy starts performing all kinds of fancy martial arts moves by spinning, kicking, jumping, and hollering. When he finally attempts to strike the opponent, the opponent simply pulls out a gun and shoots him. The moral of the story is make sure you bring a gun to a gun fight! This anti-pattern, closely relates to the anti-pattern: Nobody’s home.
My recommendation: Do an analysis and create a list of candidate services. Evaluate the value of each service independently and only create a service if it is likely to be highly reused and it provides value to the overall business goals. Make sure there is a reward for the effort!
…and here are a few patterns that I came up with
Anti-pattern: Testing is as testing does (apologies to Forrest Gump)
Many companies ignore the fact that moving to a service oriented architecture not only changes the way we design and develop, but it also changes the way we should approach testing. Duh! So I have witnessed companies pour money into tools and developer training only to drop the new whiz bang code into a QA environment and are surprised when the tester has no idea why it doesn’t work, or worse yet, if it works or not. In fact, testing of web services should be performed as a stand-alone process before the service is allowed to be consumed by any service consumer. In addition, these services should be versionable and backwards compatible, which also needs to be validated by QA.
My recommendation: Include the testing organization in your plans from the start. Train them and shift towards a more XP model where the developer and the tester work hand and hand on services. Build test harnesses and other tools to help validate that the services work before they are published for consumption.
Anti-pattern: Death by governance
Another common SOA killer is a group of ivory tower architects or development purists start with very rigid and robust governance plans. They apply too much governance too soon. The first problem is that they spend the first several months and sometimes years delivering no business value whatsoever because the time is spent arguing semantics. When they finally do settle on the rules of the game, they now need all kinds of people and tools in place to manage an empty repository. Governance is something that should have its own roadmap and should start small and grow at the speed of the maturity of the SOA initiative. In other words, the amount of governance required to manage the first 10 services is minimum compared to the amount of governance required to manage 100 services. Also, the demands on run-time governance (service monitoring, versioning, SLA management, policy enforcement, etc.) are not a line that runs parallel with the number of services built. It is more like a hockey stick where one can get by with little to no run-time governance early on but before you know it the whole house of cards comes crumbling down as service consumption takes off.
My recommendation: Carefully build a parallel roadmap for your governance model. Practice “just enough governance” and evolve your processes and people over time.
…and finally, my favorite and the one that has left me scarred for life….
Anti-pattern: Get off my lawn!
The biggest SOA killer of them all is failure to anticipate and effectively manage organizational change. Although we can argue that SOA is nothing new, we can’t argue that embracing SOA creates changes to the way people across the organization perform their jobs. Anytime people are asked to change, they need to know why, what is in it for them, why it will make things better, what it will look like when it is done, and many more questions. Often it requires deep cultural changes, with the most common being eliminating organizational and application silos and thinking more holistically. There will always be a movement against change. An organization must quell that movement by constantly communicating the vision and value of the initiative. Some people will never come around and buy into the vision If these people are influential, they need to be coached or removed. Enterprise wide initiatives are hard enough when everyone is all in. If influential people are revolting, they create issues which lead to increased costs, delays, and sometimes downright failure.
My recommendation: Get senior level buy in. Create an organizational change management and communication plan and have a separate roadmap for this that is funded accordingly. The best money spent is money spent on driving change. Without it, change will be hard to come by.
Top 10 signs you are being Cloud Washed
Here is my lame attempt at humor for today. I have witnessed a hand full of these attempts of cloud washing in person including one company showing me a slide of a rack of servers as their private cloud solution. We still joke about that one today. I hope you enjoy these and feel free to add to the list!
Upcoming SOA Blog Posts
I am embarking on my third SOA initiative in the last five years. I have led a very large enterprise wide initiative back in 2006-2008, a poor man’s SOA at my startup from 2009-2011, and now another enterprise wide initiative that spans both cloud and on-premise infrastructure at my current company. I will be blogging a lot internally to share my experiences with my company. I will repost those here on this blog as I make the posts more generic so they apply to more than just my company. The first few topics will likely focus around:
1) SOA Antipatterns – What not to do
2) Business driven SOA – If it is not aligned with business objectives you are doomed
3) Death by services – Focus only on high value services or risk drowning in a cess pool of services
4) Governance – growing at the rate of your services
Stay tuned!
Which cloud service model is right for you?
I often get asked why we chose IaaS as our cloud service model when we built our high speed transaction network in the cloud. What people don’t know is that we actually use all three cloud service models (IaaS, Paas, and SaaS). So before I answer why we chose IaaS, let’s discuss each cloud service model and some examples of use cases for each. But first, let me add this disclaimer:
There are no right or wrong answers. Any company can use any cloud service model for any reason they choose. What I am about to discuss reflects only my personal opinions based on my years of experience deploying on-premise and in the cloud.
The following image shows the three cloud service models and also shows a private cloud and an on-premise data center. Let’s assume that the SaaS, PaaS, and IaaS clouds are provided by an external vendor. Let’s also assume that the company faced with the decision has an on-premise data center and/or a vendor provided or home built private cloud.
 |
| From Cloud Computing |
My recommendations (take them for what they are worth) are as follows:
SaaS (Software as a Service)
Use SaaS to outsource all applications, features, services that are not your core competency (assuming they meet your needs and are affordable). For example, if you are not in the business of writing HR, payroll, CRM, and accounting software, don’t write this code. In fact, don’t buy the software and the servers and pay people to maintain, manage, patch, secure, and provide other non-value add tasks to keep these services running. I can’t think of many reasons other than fear that should prevent a company from leveraging SaaS for these types of services.
When we built our transaction processing service in the cloud, we looked at various Security as a Service solutions. As much as I wanted to use a SaaS solution, our business model of getting paid per transaction did not lend itself to the SaaS vendors per transaction pricing models. There just wasn’t enough margin in a transaction to share it with a vendor. So unfortunately, we had to do it our self. We do use SaaS software like Salesforce.com, Concur, Basecamp, and many more.
IaaS (Infrastructure as a Service)
The selection criteria for me when it comes to IaaS is this….If your application or service has performance or scalability requirements that require you to manage memory (ie. memcache), configure database servers and application servers to maximize throughput, specify how data is distributed across disc spindles, etc., then you should use IaaS so you can control the infrastructure level items that I just mentioned. If you don’t need to worry about those things, then you should consider PaaS.
Unless you are a cloud vendor, managing infrastructure is likely not important to any business person or customer within your company. So why do it? However, if your application or service demands extreme performance and scale like streaming Video (Netflix), high speed transaction processing (my company, Inmar), or high volume consumer facing web app (Foursquare), you will need the ability to manage things at the infrastructure level.
At Inmar, we had the requirement to process 1 million concurrent transactions initiated from point-of-sale systems within brick and mortar retail stores with a round trip response time that is less than a payment transaction (typically 1-2 seconds). We were able to far exceed that requirement and deliver sub-second response time. There is no way in the world we could have accomplished that without total control over memory management, application servers, database servers, etc. In other words, PaaS was not a viable option for us.
PaaS (Platform as a Service)
But not every application or service has the extreme processing requirements of a streaming video company or a transaction processor. Most work flow driven applications where a widget starts as an order and flows through a repeatable process flow until the widget is built, sold, shipped, and invoiced, does not require infrastructure management beyond what can be abstracted by a PaaS vendor. PaaS service models provide very reliable performance and scalability that can handle most use cases. If your application or service does not require processing beyond PaaS capabilities, why not outsource all the infrastructure management to a vendor who does that for you as their core competency?
At Inmar, we are in the process of building a robust order management system that will leverage a workflow service and even integrate with our SaaS CRM solution (Salesforce.com). We will leverage a PaaS solution and will gladly rely on the vendor to manage the infrastructure so we can focus on building business functionality.
Private Clouds and Datacenters
So now that we have discussed the different cloud service models, we often find ourselves struggling over the public vs private cloud debate. I won’t add to that debate here, although I have strong opinions on that topic. Instead I’ll discuss some options. Going back to my disclaimer, anyone can put their data anywhere they want: public, private, on-premise, wherever. If a company decides that it is too risky to put certain critical datasets or attributes in the public cloud, they can choose to place that data in a private cloud (whether it is a vendor supplied private cloud or their own) or on their non-cloudy data center. My point here is that if you are building something new and you are not constrained by any regulatory requirements, why manage this yourself? Does it add business value if you do? If the answer is yes, then knock yourself out. If the answer is no and the only reason you have is fear or refusal to change, shame on you. I have written many articles on how to leverage data services to allow an application or service to leverage the benefits of the cloud while accessing critical data locally on-premise or in a private cloud. If you want more information on that read my Data Services post.
Summary
So the next time somebody asks you which cloud is the right cloud for you, the answer just might be….”All of them”. It really depends on the requirements of the applications or services that you are trying build. I always try to spend more time on business problems then on IT problems so I try to target SaaS first (build vs rent), PaaS second (spend time at the application layer, not the infrastructure layer), and IaaS last (only manage the infrastructure layer when I have to). When it comes to public clouds, private clouds, and data centers, I try to target the public cloud when I can (cheap utility computing that someone else manages) and private or on-premise when I have to (regulations or customers demand data lives out of the public cloud).
I’ll close by saying once again, that there is no right or wrong answers. These are my opinions only, but this philosophy has lead to a lot of successful, low-cost solutions that yield reliable and scalable results. At the end of the day, you do what is right for your company, your culture, and your philosophy.
Your data center is not a private cloud
I spend a lot of time visiting customers and channel partners to work out the details of how to best integrate our cloud based solutions with their solutions. Every place I go seems to have a definition of cloud computing that allows them to claim that they are in the cloud. Here are some examples:
1) One partner has their own data center and uses VM on their servers therefore they claim “they do what we do” and are in the cloud. They do not have any automated scaling capabilities, have no automated provisioning, still have to procure hardware and buy excess capacity to support scaling, etc. My message to them is virtualization is not cloud computing.
2) A competitor who used to tell our customers that cloud computing is bad now claims to have a cloud based solution. In reality, they have a website. My message to them is building a website does not make you a cloud computing company.
3) Yesterday a partner defined cloud computing like this: “If you own the hardware it is a private cloud, if someone else owns the hardware it is a public cloud”. My message to them is your data center is not a private cloud.
If we look at the definition of cloud computing you will see these key characteristics:
- On-demand self service
- Broad network access
- Resource pooling
- Rapid elasticity
- Measured service
None of the three scenarios I mentioned above come close to having these characteristics.
Scenario 1
In the first scenario where the company uses VM they have a very limited number of servers and no ability to quickly fire up more instances. They may be able to allocate some virtual machines from their limited supply of servers but once those are used they have to go through the normal procurement cycles, installations, configurations, etc. They have no elasticity whatsoever, there is no concept of measured services, and the applications are dependent on the location of the infrastructure.
Scenario 2
Having an Internet application is not cloud computing. Geez! We have been building web apps for years. Oh, and if you throw the app on Rackspace, you are hosting your web site. Remember hosting? Hosting is not cloud computing. Hosting is renting space in someone’s datacenter. Hosting has none of the five characteristics of cloud computing. You are simply running your servers “over there”.
Scenario 3
If I own it then I have a private cloud is like saying “I am a pilot because I flew from NY to California last week in first class”. No you have a private data center. It reminds me of the early days of SOA when everybody thought they were doing SOA because they had web services.
Summary
The biggest challenge with cloud computing is not the technology. The problem is the term means so many things to so many people that the term is grossly misunderstood. When everybody under the sun can claim they are cloud-enabled then the term cloud becomes meaningless. Maybe we should start referring to the characteristics of cloud computing instead of the term itself.
The future lives outside your firewall
Many companies are still debating the value of the cloud. Whether a company moves to the cloud or not, one thing is for sure. Most of their customers, suppliers, and technology partners are going to the cloud with or with them.
To build something that is sustainable, reliable, and scalable in the cloud, it forces developers (or it should) to think in terms of loosely coupled services, focus much more on application security, and design for failure. Some of these things tend to get taken for granted when developers get a false sense of security from hiding behind a corporate firewall for years. What I am noticing is that as we see more success stories from companies deploying in the cloud, we are witnessing an explosion of APIs becoming available to us. So where is this going?
As more cloud enabled services are made available for consumption, companies that are architected to consume cloud enable services can consume these services and quickly bring new features to market at a much lower cost. Even better, having cloud enabled services may also create new business opportunities if those services are in demand by other companies.
Here is an example:
My company aggregates digital coupons from many sources so that retailers can go to one source to get digital coupons on their website. For Retailer A, we supply a coupon portal that plugs into their website and is branded with their logo. Our coupon portal leverages web services that retrieves this content through simple RESTful service calls. The UI does not need to know anything about the underlying data, it just knows how to ask for a coupon. That’s cool right? It gets better.
Retailer B has a very impressive web development team. They have built a robust web site with shopping lists, weekly digital flyers, etc. They don’t want our coupon portal, they just want our coupons. No problem. They can call the same RESTful services that our coupon portal developers call. In this scenario, a shopper builds a shopping list on the Retailer B’s web site and Retailer B’s web site calls our services and returns coupons that are pertinent for the shopping list. Even cooler, right? It gets even better.
Retailer C outsources their entire website to Retailer Web Supplier XYZ. XYZ has an awesome Web 2.0, social media connected, rich media website. They also have a recipe application, a Facebook connector, a smart phone app, and much more. So we partner with XYZ and they make RESTful service calls to get specific content from us and they parse the XML to populate their web pages with the information they need. Guess what? XYZ has many retail customers that are using their services. We just created a new business opportunity because our service that delivers digital coupon content has value to a company with many customers. XYZ would rather call our service than build what we have already built. It’s a win-win!
This is the future of business. Many companies are going to start specializing in specific features delivered as services. Companies are going to be sharing more services and building composite applications made up of the best services that satisfy specific requirements.
Here is another example:
Let’s say our customers start asking us to deliver content based on geo targeting. Do I want to create a project to build and maintain a process that gets a feed of various geographical data points and manage a database or do I simply want to make a web service call to a service provider that has already done that for me? You bet I want to make a service call and not create another application to build and maintain, especially since it is not a core competency of my business. I may also want to display a visual map of the retailer’s stores with counts of shoppers using coupons at each store. Once again, I’ll use the Google Maps API instead of building mapping technology.
The pattern here is clear. As time goes by, our applications will consist of more cloud based services from many different service providers. This is not a fad, this is the future. The future is in APIs and that future lives outside the firewall. So whether a company believes in the cloud or not, the future is in the cloud and if a company can’t take advantage of it, the world will simply pass them by.
Building Enterprise Solutions in the Cloud
I recently spoke at the Business of Cloud Computing Conference in San Diego on June 15 and gave the following presentation.
I started the presentation by discussing how my startup, M-Dot Network, built a high speed and secure transaction network that connects Point-of-Sale systems to our cloud in real-time. I talked about how three guys on a limited budget built a fully redundant virtual datacenter in three Amazon zones on a shoe string budget. Then I moved to the first slide and said “I’m Mad”. Why am I mad? There are lot of pundits out there stating opinions as facts and declaring that the cloud is not secure, the cloud can’t perform, and on and on. I am mad because every vendor under the sun is “in the cloud” now and distorting people’s perception of what the cloud really is. From Microsoft’s ridiculous “To the Cloud” commercials, to vendor funded white papers that create fear and then describe their solutions that combat your fears, to the “me too mega vendors” who were late to the party and try to sell you the same crap as before but now in the “cloud”. I am also mad because whenever any cloud provider has an issue or outage, everybody screams doom and gloom for the cloud. My favorite is when GMail has an outage. People act like their corporate Exchange server is more reliable…..please!
Just because companies fail in the cloud doesn’t mean the cloud is not good. My favorite slide is the slide with the faucet and the sink which are clearly out of alignment. On this slide I compare the sink situation to the outages companies experienced when Amazon had some issues recently. Companies who built in redundancy did not have an outage, those that did not were down. So looking at the sink picture, would you say sinks suck? No. You’d say the plumber sucks. Get my drift?
The rest of the presentation focuses on the steps one should take to build enterprise solutions in the cloud. Start with asking “What problem am I trying to solve?” I have seen people declare that they need to build a private cloud. When I ask why, many don’t have a good answer. Some simply want to reduce their server footprint. If that is case just put some virtualization best practices in place. Don’t buy a plane when all you need is a plane ticket!
Next, define your business architecture. After all, you are doing this for the business, right? Then understand your requirements as they pertain to data, applications, infrastructure, and processes. Once you clearly understand the problem to solve, the business architecture, and the corresponding requirements, now it is time to understand the cloud service models. Read the CSA Guide v2.1. This guide is a great source of information that outlines many things to consider when using cloud services.
The rest of the presentation focuses on things to consider when building high speed transaction systems in the cloud. You may notice that these are the same things to consider if you were building this on-premise. It is important that these types of questions are addressed. One must truly understand and anticipate the network and data needs in order to properly architect a solution that can produce the desired high speed results. For example, the requirements to deliver 144 byte Twitter streams are entirely different than delivering streaming video like Netflix does. Also, processing fast database reads is an entirely different art than processing database writes. For example, if a process is being built to access large amounts of read-only historical data, a no-sql or flattened database/star schema architecture is more suitable than a traditional relational model. So understand the requirements before settling on the solutions. In other words, create the blue prints of the house before buying the materials for the roof.
One point I made was that in my opinion, I think IaaS is required for building high speed transaction solutions. The reason is simple. From my experience, creating sub second response times for millions of concurrent transactions requires control over and configuration of the operating system, application servers, the database technology, and memory management. With PaaS, you are at the mercy of the standard configurations that the PaaS provider gives you.
To sum it up, success in the cloud is all about architecture. Everything can and will fail in the cloud (as it does on-premise) so you better plan and design for it. If you don’t, don’t blame your cloud provider. Your end users don’t care if your vendor fails, they care about your apps uptime. Leverage the cloud for what it excels at: scaling up/down, backing up data sets, provisioning on demand resources, etc. But also architect for the clouds weaknesses: security, compliance, etc. And finally, architectural decisions are influenced by budget, resources (skillsets, experience, number of) and time. The architecture we put in place with M-Dot would likely be different under a different budget, with more resources, and if we already had a datacenter in place. So don’t let anyone tell you that there is only one way to do something. Architectures are like finger prints. No two are the same.