Office 365 vs AWS

I am not talking here of the task of AWS vs Azure, but the fully SaaS Office 365 vs the PaaS and IaaS of AWS.

These 'opinions' I have been gained by hard experience, and though things are changing I think I am coming to close to a general set of principles about how larger enterprises should work.

If you are a start up you can stop reading here, start up has massively unique opportunities to save money with technology that a bank or government department will not have.  I am talking about medium to large established companies and agencies with established IT.

Firstly just migrating existing VM and containers to the Cloud as IaaS is not going to save you much money.  I have seen this at both ends, in the detailed planning phase for migration with both AWS and Microsoft Azure and working with a live IaaS system that hosted all the servers of a major enterprise.

Right up front I will tell you that if you move all your servers to IaaS either AWS and Azure and do nothing else, you are going to not see much difference between on premise and Cloud.  For firms that consume managed services the two are going to be pretty much the same, you get a bill and the bill is going to be pretty much the same.

So to get the benefit of Cloud you need to make transformations, and what I am seeing is that it is best to break your entire IT estate in to 2 major groups.

I know officially what you are suppose to do is review the business case for each system you migrate over, deciding a final destination based on the application and rationalising the application before you migrate.

In a live talk this is when you ask a room for of CIO and CTOs how many have a full understand of the business cases for their applications and the latest architecture they use.

The reality is a data center is going to be full of lots of systems that are not fully understood to anyone in IT as a group.  You may have certain people who fully understand a system or group of systems, but as you move out you inevitably get a poorer and poorer understanding.

And lets be honest, you are unlikely to have staff or afford experts who have the skills to go to each team that manages a system, to get a full understanding of the business and technical parts and communicate accurately to management.

The hard truth is that in established IT systems you can only do so much discovery, a full discovery is prohibitive by cost and time and frankly may not really even be possible.  If you have been around for more than 10 years you have a great deal of legacy stuff maybe one guy remembers and each time you talk to the one guy he keeps harping on about....well we all work with technical experts don't we.


What migration to the Cloud has to deal with is uncertainty.  Uncertainty is just a part of life, it seems to be backed in to the very fabric of the Universe and IT, if anything, only increases it as systems become more complex.

So what you need to think is 'what kind of uncertainty does this service face.'

What I would suggest as a first pass is looking at specific vs general uncertainty.

Specific uncertainty is what we usually always think about.  A system sitting on a server is old, it has a wide range of users many sharing the same login access, and it lacks updated documentation.   You know the system is doing something, but you can't be fully sure of what.  It was designed for a specific task that may be only partially understood, and users are unable or unwilling to communicate and cooperate with anyone wanting to change their systems.

We all know this.

But there is a very different kind of uncertainty that we don't fully grasp.  The uncertainty of what is in emails, SharePoint or Word documents, what is entered in the Salesforce.com of CRM systems or lives in SAP.

We know a great deal about these systems as they are industrial standards, but because they are widely used applications, but you can't understand what is inside of them, how people are using them and what value they really create.

These two types of uncertainly should be managed in two different ways in the Cloud.

Traditionally AWS manages the first, you have a mass of VMs you know you need on your estate.  So you migrate them to the Cloud, which in itself saves no money.  So how do you save money?

You look at the usage patterns and start modifying up time, CPU count, storage, bursting and commercial things like reserved or spot instances to save money.  What you do in this you take the high level view looking at how the systems perform as servers to assign more agile systems to them.  You also may migrate things to better platforms, ending a larger EC2 Windows server with IIS to run PHP to a BeanStalk with stores data on S3 and load balances micro servers to meet just in time demand.

But what about SharePoint, Exchange, CRM, does this work?

Here I would say the different kind of uncertainty means a different kind of road to cost savings.  You know perfectly well how these systems are architected and what they do, and you could reduce costs, but you have an opportunity to leap frog all of that, and move to the most optimal Cloud hosting directly by moving to SaaS directly in the form of Office 365.

In these system where you know the kind of tasks that people do, but have no idea the meaning to them of what they are doing and, as you would need to run two companies to know what everyone in the first is doing all the time with data, you probably are best just to start defining the roles that can use standard software.  Actually as the skills of workers increase they tend to use more tools than forms, Excel, Word, PowerPoint and SharePoint are flexible platforms.

Rather than migrating these servers my experience is you will save way more money pushing an all in with Office 365, and a major effort to see how may existing systems written with say .NET can be provided by SharePoint sites.

So to sum up:

• If you have a lot of little boxes running code you don't fully understand for reasons that are unique to a community you are probably better migrating them in mass to AWS and working on reducing their consumption latter on by turing servers off, allowing autoscaling, and migration to better platforms.
• If you have a massive system that many or all employees use for various different reasons, that is fully Enterprise, you are better looking at buy a SaaS replacement.

The main point is that you can only really know so much about the details of your IT, and in only so much accuracy, you need to plan for moving things in mass without disruption, and then how you save money.