Microsoft Azure – or how to make the public cloud work for you Public cloud computing offers the tantalising promise of elastic computing, but few IT practitioners know what it means, let alone how to make it work for them. My job is to know this stuff, the new and cutting edge of IT. I need to know it to educate my clients, but also because I get paid to write about it. I have worked …
Thanks Trevor. I was very much of the same opinion as you before working with Azure. Old-school IT folk are scared of it partly because it threatens to make their specialist skills redundant - you no longer need to know about that obscure IIS machine.config file setting, or whatever your particular angle is.
This post has been deleted by its author
Not entirely in agreement there. Theres a lot to like about the "everythings a service" model, right up until it falls over and you have absolutely no way to know what has gone wrong, how it might be fixed, how long it will be down for or indeed any real way to influence any of the above - your service is simply down and its cross-your-fingers time.
Building across multiple cloud providers is possible (and there are a number of possibilities here) but that loses a lot of the "push button simple" that is compelling in the first place...
...you have absolutely no way to know what has gone wrong, how it might be fixed, how long it will be down for or indeed any real way to influence any of the above - your service is simply down and its cross-your-fingers time
The above is a fairly accurate summary of how many developers in large companies feel when something goes wrong. You have to start raising tickets, only you don't know why the database server isn't responding - it might be the DBMS, it might be the OS, it could be the hardware, or it might be some network configuration gone bad. Yes, I can do a lot with ping, tracert etc, but ultimately what I don't have is control. Or access.
It is partly because of the "death grip" to which Potty alludes that cloud services are so desireable to devs - more flexibility with few downsides - we already don't have control. Clouds (paperwork aside) mean I can spin up pretty much whatever I need for not a lot of money. I still get to raise a ticket for help, and I still don't really have visibility of what is happening or why, but when it does work its very very slick.
>I need to redesign my applications, my entire user infrastructure, how I handle emails, DNS and pretty much everything else,
I had a close encounter with AWS recently and discovered that herein lies the key. If you are starting from scratch, cloud (public or private) makes sense, but you need to write for the cloud not for the enterprise or the desktop. i.e. worry more about latency than bandwidth. Look at gmail: once you've logged in, the emails listed on the page load their text even though you can't see them. Even if disconnected, at that point, you can read all the emails listed. Text is small and cheap to pre-load. Going back to the database to pull the email text when you click on a subject line, is expensive and slow. Anticipate what data the user will want and pre-load if you can. Don't worry too much about browser RAM, users will have far more RAM than you will ever want to fill with data.
Bunging your exsting enterprise app VM onto someone-else's infrastructure is not "cloud" in a way that will make users happy. You probably need to start from scratch and you need software which doesn't scale licensing fees whenever you need to embiggen. Otherwise you run the risk of getting DDOS'ed in the pocket.
There are two type of company - those that under-fund IT and those that mis-fund IT. In so many places I've seen (expensive) load-balancers fronting multiple services but behind them is a web tier where lots of two-node apache clusters look after a single service. There will be lots of server-pairs running different services, instead of loading all web frontends across all servers and then using the load-balancers to scale and distribute. The reason is that the web tier is cheap: Apache, Linux and a bit of iron and service owners want control. For mission-critical things, it isn't a (cash) problem. Where things become horrible is the backend. It is a mission critical app, so Oracle or sometimes MS SQLServer. All of a sudden flexible scaling, while technically possible, becomes costly. The neatly regimented and controlled perimeter gives way to a messy corporate LAN. Load-balancers which do so well distributing TCP 80 and 443 connections, suddenly have to do deep packet inspection and fiddle with the gibblets of SQLNET which means that expensive kit doesn't scale as well and isn't quite as reliable or easy. Architects and service owners look at the costs and decide their service doesn't need to scale so they'll opt out of the load-balancing costs - after all, its Operation's job to keep the thing running.
So the thing about the cloud is that it is essentially outsourcing. It may not save you money. The fact that someone else is taking a slice of profit means it probably won't unless you have very unpredictable demand or you are too small to make the investment in load-balancers. However, sometimes the value in outsourcing is to ditch IT, IT personnel or service-owners' mentality which/who have become a drag on the ability to provide service. Sometimes the value in "cloud" is the dashboard. The automation which means that configuration is not done by hand, making it less prone to fat-fingeredness. You can load up your infrastructure if you can be confident that some admin isn't going to take your service down while dealing with some-else's. Perhaps the value in the cloud is the fact that service owners and architects don't get to cut corners because they don't have control of the infrastructure.
It will be interesting to see if the containerisation of services means more or less income for MS with Azure. Will AWS and others be able to mimic or gateway integration from areas in which MS is strong, such as corporate infrastructure? Is cloud-based Exchange/Lync vulnerable to drop-in replacements?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
