MaxBuchler
- 21 comments
- 6 likes given
- 20 likes received
Bio not provided
Good points. Outages is part of the game and they will exist, regardless if on-prem, priv or public cloud. It's how you handle them that matters. Yes, it is about marketing and risks and sometimes penalties (money and/or market reputation). No one should promise AND expect 100% if ANY part in the service or product can fail. And if you're still cocky enough to promise or calculate (expect) 100% the harder you fall.
@comparethecloud To not change focus from Richard's great post and important subject; would it be a good idea if I post my (a bit long) reply as a separate post?
@Andrew Cuthbertson I will reply to this one during the day and try to keep it short. :) It's possible we're discussing different clouds and the complexity and scope of the service.
@comparethecloud Thank you! Sorry, flu one week and now selling the house... Soon be back on track.
Richard, great post and I look forward to the next part. My comment: I agree you should check up on your CSP or reseller but I do think we have a problem if we have to check up on what hardware the service is running on. Of course it depends on what service you adopt and data you put in the service (= how business critical) but don't you think we need to put in more trust on the CSP? We should never be careless, we need to read the T&C (or says on the tin ;)), do the compliance, lock-in, security, compatibility, SLA etc check's, but if checking to deep nitty gritty it will take too much time etc. A reference is good but shouldn't be trusted as fact, though rumor might give you a hint. Couldn't that be somewhere enough? According to me; one part of what you need to let go when adopting cloud services is the detailed control of everything and put trust in you CSP and put more effort on information management. Sometimes you get what you pay for but I really do think that if you adopted a service produced in the bed room or in the cellar you haven't done your basic homework well enough.
Great post Robert!
I realized my comment could be read a bit snooty. I apologize in beforehand; my intention was to salute Abduls post and to add “verified” pros, not to brag. Truly sorry.
Great post Abdul. I end up with a short bio to “verify” my comment, so it’s not a commercial. ;) In general I agree to your post but I want to add some points/pros. Thin clients: - Cost approx. the same as a mid-range computer. But there’s definitely some pro’s like ROI; less power consumption, fewer parts can be broken, longer life cycle - Minimize theft of the physical device itself - Low > no noise - Even if longer life cycles it’s not true they can live forever. It’s a myth that needs to be ripped apart. Multimedia etc demands more power and better techniques = new TC’s VD: - A perfect start in a BYO-program - More or less device independent - As you say you can quickly roll-out upgrades, new apps etc. But you’re also able to easily roll-back if something goes wrong. - Possibility to provide different OS and app versions to different users - Possibility to provide two or more apps to a user, apps that normally aren’t compatible with each other. - DaaS for MSP’s and CSP’s. - Management! Bandwidth: - Bandwidth might be a problem if you allow aero UI, audio and video. Today it’s very difficult to tell bandwidth per session. You should restrict this if needed with policies, both written- (staff handbook) and group policies. - In most of the European countries there’s really not a bandwidth problem anymore. Short bio: I’ve been working 15 years at a leading Nordic SP of ITaaS and ITO based on a multi-tenant VD platform. In March last year I wrote a post named ‘”Citrix? Whew!” Or?’(http://inmaxmind.blogspot.se/2012/03/citrix-whew-or.html) to “re-release” faith in Citrix and primarily XenApp which the multi-tenant VD platform was based upon. I ended my employment at the SP in September and now more run my own consulting business focusing on advisory in Cloud, ITO and ITaaS.
@RazorthornChloe Certainly agree. Business is not Jeopardy!
@comparethecloud I think my comment to @RazorthornChloe explains a bit what I think. Some adoption, especially public cloud services, won't be practical (or even possible) to DD too much where Next > Next > Next > T&C > Accept is the process. This is why the roles of Trusted Advisors, Brokers and Experts will be very important. They should be able to analyze, advice and support.
@RazorthornChloe Great advices. Of course facts are important, the combination of facts AND reputation. (It is references you shouldn't "trust".) Trusted independent reviews and advices are important in cloud adoption and future IT and I predict it will become even more important the coming years.
James, to explain my question a quote: "The one thing I can see right now with 100% clarity is that at some point in the next year or so one of the larger cloud vendors will have a catastrophic security event that will destroy their brand and reputation. It will be a wakeup call for the survivors..." I often tell customers and the market you have to trust CSP's in security, continuity etc and let go of detailed control. They should focus on compliance, T&C, lock in etc and choose on reputation (not references), value etc. You buy top security etc when you adopt a cloud service is my saying. You shouldn't have to verify and control as you have to with your own on-prem (let go of detailed control). This one of the advantages of cloud computing - to focus on value to your business. I'm also saying you should think and plan well before you act. I know the effect will be devastating (for the CSP and all its customers) if a larger CSP is affected by a larger incident related to security or outages. My Q: Should organizations be afraid of adopting cloud services, even from well-known CSP’s with good reputation? And should organizations NOT let go of detailed control?
A comment from the non-techy guy. Orchestration solutions are really needed. At the same time it's also about orchestrating your customer. As an IT department, ITO, appl operator etc you have to start think as an orchestrator, it's not only about technique, in: service management, governance, partnership etc. Take the possibility to be the trusted advisor and orchestrator to your customer, someone has to and someone will. My old post the Orchestrator from September last year more in detail explain the way I reason. http://inmaxmind.blogspot.com/2011/09/orchestrator.html
Sorry about the formatting....
A lot of really great comments and traffic to a great post in an important matter. First and this is important; I’m not an InfoSec expert, at the most I would call me novice. So my points are in humble respect to all InfoSec experts. And I apologize if I’ve missed comments similar to mine in the thread. But, I will give you my opinion from “my mind of view”. I make it a long one… Normally I use to say: Don’t worry about security in the cloud. It’s probably better than the one you have today in and around your on-prem solution. And if it’s better “at home” you either: - Have a specific business that needs to be top secure. Most probably you shouldn’t put this type of service into a public cloud. Maybe a private one. Or: - A specific CSP have a lousy security solution – a minimum solution! Or: - You have probably built a better solution than needed + your owner or the management isn’t informed or don’t understand the actual cost. CSP’s core business is to deliver services. If a CSP fail in security it’s a bad mistake and the CSP should, in my opinion, ask themselves why they are in the business at all; in the business to make easy money or truly deliver a good service to customers? The business is self-sanitizing but it’s bad for cloud business in general if credulous customers learn the hard way. By saying credulous I don’t mean sloppy. You should read T&C and benchmark but you should be able to trust the facts and results. On the other hand; CSP’s struggles with costs since customers demand more than they are willing to pay for (read my post about that customization isn’t the future on outsourcemagazine.co.uk). It might also be a problem when a customer asks for i.e. a SaaS where InfoSec isn’t a selection criterion and several CSP’s compete about the contract; why should the customer choose a more expensive service even if it’s better?! To me this is the biggest problem: Customers choosing the cheapest alternative even if they (know?) needed a better solution - the unaware CFO and CEO putting their businesses at risk because they didn’t understand, nor aren’t aware enough, just thinking about money in short term. To quote a colleague of mine: “When buying quality you only cry once.” For sure, as in all situations; attacks will happen where it hurts the most. So CSP’s will be more attacked and vulnerable than single on-prem solutions. Therefore, I still say; Security is probably better in the cloud than with a business functional on-prem solution – because the CSP will be “erased” from the market if it fails. Security shouldn’t be a defense wall only. The only way build “Fort Knox”-security is to use tons of money. Or you can erase all threats by dropping the Internet-connection, use rigorous controls when hiring and when the employees comes to work. But business is about taking risks, not stupid ones but some. You can’t afford “Fort Knox”, you can’t “afford” dropping Internet or setting up rigorous controls and you can’t afford incidents. You have to know threats and what risks you’re taking and try to minimize them, but most important; you have to know what to do if something fails or someone hurts your business. If you put the least acceptable level of effort (=minimum) to fulfill a certification, standard etc you as a customer jeopardize your business or as a CSP jeopardizing both your own and your customer’s business. If you know you’re doing minimum…reconsider if you should be in business at all. Unfortunately the customers are driving the “minimum”. Let’s hope maximized security bangs aren’t the way to wake customers up from security minimalistic dreams. Minimum is not ok – for me, you, he, she & it/IT, and none of us can afford a serious incident. Good q's are: What is maximum and what's "enough"?
@sarojkar Yes, I certainly agree. There should be no such thing where CSP’s can get away blaming service outage because of the underlying functions/infrastructure (including bugs – choose another part from another vendor if buggy). It’s the CSP who choose which part’s building their service. If the CSP doesn’t choose great and reliable parts the customer shouldn’t suffer because of bad choices. Unfortunately these might be risks the CSP calculate, where the SLA and penalty becomes just some numbers. Hopefully not but it might be a risk for the customer. Since it’s more accepting T&C’s than negotiating contracts when it comes to cloud. Therefore, as you said earlier; compare/benchmark, check for references and read T&C’s carefully. Also; as a professional business you should always analyze risks, impacts etc. whether cloud, ITO or on-prem and don’t end up with your pants down - outages do happen.
I'm not sure whether you mean adoption or the quantity of euro CSP's/euro CSP seats but I assume it's the adoption of cloud in general. There is definitely a problem with EU and cloud adoption. And this is according to me quite difficult to both explain and solve and definitely to comment in a comment :). One easy way is to say that the problem might be the lack of well-known CSP's (exception does exist) in the euro area and the "problem" with EU laws vs US great cloud services and well-known US CSP's, which for sure dominate both the cloud and the on-prem market. I think many EU companies look at the possibility to adopt US cloud services but laws sometimes say it's not possible, so; there's a problem. But I think we should dig deeper in to the history of Europe. Sometimes it's referred to as a unit or country (like the US with several states). Some people in Brussels and in EU also seem to have that same kind of Nirvana thinking. But it's not. After WWII a co-op between some European countries started and in mid-90's EU was a fact. Today EU has 27 member nations, as you say; a lot of nations. I would say these 27 nations talk about 20 different languages. These countries all have a long history incl wars (often against each other), epidemics, rise & fall etc. They have their own culture and laws as you say. Since EU is quite "young" it takes time to tweak (CloudTweak!) laws. The fact that countries have own agendas and different history etc etc - it's not making anything easier. It's a prob. When a Swedish (I'm Swede) company want to adopt an international cloud service they have to look at Swedish laws AND EU laws. Plus, they think like Swedes, exactly like Germans think like Germans. Companies either stay within their country by adopting a domestic cloud service or traditional SaaS or they start to look at services delivered from well-known CSP's around the world = US CSP's. Seldom would an EU country look at other EU countries CSP's. Swedes might look at UK because of the language but a French company would possibly not look at what a German CSP offer, and not only because of the language... I really think that many of the "ifs" is in the history and the fundamental misinterpretation that everyone in EU can play with each other. A lot of people still think they are “Swedes” and not Europeans. But I really hope and think EU companies will start to catch up, not because to catch up or compete with US, because EU countries need cloud services. As said; this is hard to "just comment" but I hope you understand the basic point - it's not as easy as you might think, it's not only slow bureaucracy and sometimes stupid laws creating the problem, but we will catch up. I will try to convince people in my coming post on KYC: The Multiculti Cloud. Great weekend. Max/Swede/European ;)
@sarojkar Do you mean like a complete chain with several services included in a "full" ITaaS/XaaS? Or do you mean net, servers etc within the DC included in a SaaS? (Then it definitely should be included in the SLA) If ITaaS; it's definitely cool to deliver the chain of services from DC to user. It's a risk but definitely cool, you will certainly differ from many other SP's. As long as you can control services and functions in the chain + secure important and sensitive functions with redundant or hq components + not to forget; deliver top notch stable IT services, I would take the chance – you differ on the market. The weak part, according to me, because it's normally out of your control, is the carrier. A cloud service should normally be available from I-net and I wouldn't guarantee the whole chain when I-net is a part of it (which you of course could disclaim in the terms & cond). To me the chain delivery model is more applicable in an ITO model than in cloud, maybe in a private cloud. I agree: you should compare.
One thing I would like to add; non claim based penalties. The CSP should without a claim from the customer either pay a penalty or give a discount when the service doesn't meet the SLA. The customer shouldn't need to claim it.
Balaji, I agree with you. The 2-5 are pretty much known but the first one isn't well known but maybe the most important since it's more of a feeling than a pretty well defined threat as lock-in. The first one is a jungle more than a fog. The good thing is that jungles can we do something about. Not desolate but disforest. It's easy to start a business in the cloud but it's more difficult to keep it alive. A lot of gold diggers to watch out for. That's why I think trusted brokers, aggregators and advisors are absolutely necessary to consult when adopting cloud - they can help customers disforest the cloud jungle. SLA in general should be taken seriously but I think most reliable CSP's do their job and it's more a problem for a specific CSP than the market.