Why You Need To Think Very Carerfully Before Adopting A Service-Oriented Architecture Model

It's the latest craze - take whatever you can think of in IT and networking, and add "as a service" to the end of it.  Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS) are the three main types, and all the other xxx-as-a-Service types and aaS abbreviations can be classified as Infrastructure-based, Platform-based or Software-based.

WHAT EXACTLY IS IaaS, PaaS & SaaS?

Seems like a good place to start.  Basically they are 3 ways of moving your IT operations into the "Cloud", allowing you to (theoretically) scale your IT needs as and when you need.  There's an awful lot of blogs, adverts and talk about why you should be going down this route, but very little on the negatives, possible pit-falls, and ultimately how it can totally kill off any chance of anything innovative coming from your in-house IT guys, or being able to adopt others' innovative solutions.

Let's consider the following table:

Here we can clearly see the difference between the three, and ultimately which parts of your company's IT you will lose control of, instead putting responsibility in the hands of your provider and away from your in-house IT department. 

The reason the "as a Service" model is so popular is purely down to costs, very rarely will this route be implemented and embarked upon by anone other than Directors at board level looking to streamline and reduce overhead costs in the IT department.  With IaaS you have no datacentre co-location fees, no rack power costs to pay for, no hardware to buy and maintain.  Just a monthly fee that's probably tied to cpu time used and/or bandwidth.  

IaaS takes your IT hardware and network infrastructure and virtualises it "in the cloud".  This (theoretically) means that your IT hardware and the "network" it's running on can be scaled up or down depending on it's load and resources needed, and (theoretically) reduces downtime caused by hardware failures.

PaaS is probably the most favoured option at the moment.  You can think of PaaS as a shared Web Server from 10-15 years ago, but virtualised and in "the Cloud" rather than an actual physical box in a rack.  With PaaS the provider is responsible for the job of hardware, network, OS, Service Delivery apps (eg Apache, MySQL DB etc) and the runtime libraries and resources (eg PHP packages, Perl etc).  The customer is left with responsibility for the data and the end-user applications only (PHP scripts, HTML, Web-based app etc).

SaaS is where you have basically outsourced all of your IT.  Your staff use a web interface or similar, and everything is hosted and stored centrally in "the Cloud".  There is no hardware or software to buy, maintain, patch, upgrade etc. just a monthly or yearly licence (usually per-user) fee (some providers will charge based on data usage rather than number of users).  This is basically the same model as all computer systems used in the 1960's and 1970's when "the computer" typically was an entire building built solely to hold the massive mainframes of the day.  Users would use "dumb" terminals, like the venerable VT100, connected to the mainframe via serial connections.  The users would use a VT100 to access the mainframe and do their work, and all processing and data storage were handled by the central mainframe.  The only way that SaaS differs from this model is the ability to scale the storage, computing power and delivery/availability (read: number of HTTP sockets, number of DB connections etc) due to the virtualised nature of the hardware it's running on.

The VT-100

That's a broad summary of the three - I may have worded things wrong or badly explained some bits, so don't take it as gospel and use my definitions as part of your migration plan.

Now let's look at what you should consider before even thinking about making all your Sysadmins, DB admins, Tech Support, Web Developers and the rest of the IT department redundant, and before you cancel your Co-lo contracts and throw all your IT hardware away.... (No, seriously - some companies really are going down this route with many more considering the move).

 

LEGACY SYSTEMS

Firstly, and probably most importantly, you need to look at what legacy systems you have in place.  For instance, at the heart of some nuclear power plants you'll find a PDP-11 controlling the operation of the reactor. In 2011 it was reported that the US Navy's Food Service Management System was still using MS-DOS.  Legacy systems can be hard if not impossible to remove for a variety of reasons - it may be that the system is mission-critical and cannot suffer downtime (UK Air Traffic Control Radar ran on a PDP-11 for 25 years), it can even be as embarrassingly simple as the person who installed it is no longer with the company and didn't document anything or the documentation has been lost and the function of the system is no longer understood; the system performs a function that is difficult or impossible to replicate; and many other varied reasons as to why that 30-year old pile of crap in the basement is still plugged in and chugging away.  This one thing alone may preclude you from being able to adopt an "as-a-Service" approach and may mean you have to keep some of your coffee-fueled IT guys and keep some things in-house. (Sysadmins: quick, burn all your documentation, never build in redundancy, and make sure you overly-complicate the simple tasks in your organisations IT!).

 

CERTIFIED HARDWARE AND/OR SOFTWARE

If either you or your customers require industry certification for either legal or contractual reasons, you will run into problems if your ?aaS provider doesn't have the correct certification.  It may be that you're holding sensitive data and are legally bound to comply with and be certified to an ISO standard.  It may be that your entire network has to meet ISO standards for security management and you're thinking of switching to a SaaS solution...  Whatever the reason or certification, you may find yourself in the unenviable position of needing to get re-certified.  This can take weeks or even months of costly auditing, and may just prove impossible to do because your Cloud-solutions provider does certain things or has procedures that are non-ISO compliant.  The cost can run into the tens of thousands of pounds.  If you or your customers require certification then you will need to plan and execute your move to ?aaS very very carefully and thoroughly.

SIMPLY MOVING YOUR EXISTING ON-PREMISES SOLUTION INTO THE CLOUD

You might think that you can just take your current network, hardware and (configured) software and just re-create it in the Cloud.  This is A Bad Idea ©.  If it is purely a cost-cutting exercise then I would recommend getting a meeting together with your head of Accounts and as many managers and directors as possible, and maybe explain all the risk and work involved in moving to the Cloud, and how it removes the ability for the company to be able to innovate and come up with your own tailored bespoke in-house apps and systems.  Your move to the Cloud should be driven by performance, availability and/or capacity needs.  As a result of this, your migration plan should involve the redesigning and streamlining of certain bits of your systems/apps/DB/web where possible - you should be tailoring here specifically for scalability and security.  You should be migrating your IT systems with your head quite literally in the Cloud(s).  So, if it's cost-driven you perhaps need to point out that you already have the physical assets and related peripherals in place, and what they're proposing to do is rent instead.  You should also point out the old adage of "if it ain't broke, don't fix it".  Any move to the Cloud and "on-demand"-style software should be done for the right reasons in the right way, or all you'll be doing is taking your existing set-up and exposing it to new potential security flaws and potentially old, outdated procedures not designed for the new architecture.

DIRECT HARDWARE ADDRESSING NEEDS

Sometimes it's just not possible to virtualise everything.  Any program or scripts that need to address hardware directly for whatever reason are going to have problems when that hardware is virtualised.  It could be anything from a physical sensor (eg a temperature probe or similar) to a peripheral that needs an RS232 serial port to communicate.  One of the most common is needing to address the network hardware directly, or needing two or more physical network cards (although the majority of software that demands physical direct-addressed network hardware performs funky routing tasks, such as the Linux Advanced Routing & Traffic Control project, and since we're virtualising our network any way, it would be prudent to move whatever task it performs to the virtualised network layer of your ?aaS implementation, as technically you're not responsible for network configuration or operation any more.  It's now your providers responsibility.

UNRELIABLE INTERNET CONNECTION

It should be of little surprise to hear that if you haven't got a rock-solid internet connection (ideally you'd want a secondary back-up connectivity option, maybe broadband through a different provider or a 4G hotspot or something), then moving all of your IT systems to the "Cloud" is really not for you.  Your company's productivity may suffer somewhat if your staff spend half of their day staring at a computer screen that looks like this:

MULTICAST NETWORK

If you use multicast in your network (most commonly used in streaming media applications) then moving to ?aaS probably isn't for you.  You'll have real difficulty in finding a provider that supports it, however the IEEE claim that multicasting is possible in this document here, but discussion of that is beyond the scope of this blog post.

OTHER DRAWBACKS/CONSIDERATIONS TO MAKE

• All systems and data must be online.  It is not possible to have an isolated, non-networked, non-outside-world-reachable machine/environment. Some examples where this might be used is as an SSL/SSH certificate generator or storage for extremely sensitive data
• Some situations it's desirable if not essential to have a local on-premise server of some kind.  It may be your IP PBX has to stay located in your sales office as your main sales number is a standard, non-portable geographic number that your supplier can't relocate or route through to a PoP or datacentre that your cloud provider has a presence in.  In this case you have little option but to terminate the line(s) at your premises on an FXO card or similar.  If you have multiple office sites, all with non-portable geographic numbers, then you are going to need a PBX at each site and some sort of encapsulated point-to-point link between them all.  In this sort of situation I would want by PBXes to not be available to the outside world and general public but still want to retain IP connectivity so the PBXes can talk (pun!) to each other, pass over calls etc.  I would do this using SSH tunnelling between the two sites with PBX-PBX communications secured and encrypted from end-to-end.
• Problems can be hard to spot, which is why monitoring is vitally important on your Cloud platform.  You need to know when your server is under high load or using more resources than expected as this could be a sign of some misconfiguration errors or a broken script, or could be the result of a malicious hobohacker DDOS'ing your Cloud instances/virtual machines.  This is where the ability of the "as a Service" model to scale on demand (and to be able to do it seamlessly and automagically) can get you into problems.  If you have no monitoring and your site is under an undetected DDOS attack for a month, happily scaled away and serving 10,000,000 sessions a minute (instead of 10 a minute when not under attack), then you'll suddenly find yourself looking at a bill at the end of the month for the use of resources and bandwidth which could be more than your previous years' entire annual IT budget!  I cannot stress this point enough - if I haven't made you worry about how to effectively and accurately monitor your resource usage and traffic to the point of being permanently paranoid, then I have failed in explaining it properly.
• Be prepared for some vendor lock-in and lack of flexibility - be prepared to have to conform to your provider's best practices instead of your own.
• Ultimately, whatever happens, from now on you are going to lose some if not all of your ability to innovate and experiment with IT solutions.  I mean, for one you've only got a couple of PHP developers left and a drawy picturey chap (sorry, graphic designer) left in your IT department now.  You made all the Sysadmins, Tecchies, Netadmins and people with networking knowledge redundant!  This model may suit a lot of companies - let's face it, if you're running an e-commerce site then you only make money when people are shopping.  By streamlining your IT department and outsourcing everything but your developers and designer, you can now put all of your efforts purely into maximising those click-throughs, goals and conversions and ultimately sales.  You have lost the ability to create tailored, bespoke optimised solutions, and instead must rely on bloated, generic libraries and software that is standardised  - this make maintainance of your code easier (theoretically) and should help avoid errors.

IN SUMMARY

The Service-Oriented Architecture model is not ideal for everyone.  It should not be adopted "just for the sake of it".  It can help with scalability and can allocate resources in an "on demand" model.  Ideal for a web site that is promoted once a month by a (double opt-in) email blast.  For 29 days a month the site gets very little traffic, but with the mailshot the web site gets hit hard - too hard for a single machine to handle.  In a traditional set-up this would mean clustering and load balancing a pool of web servers to provide the capacity.  Obviously this would mean you'd have an expensive load of hardware sat idle for six and a half days a week, costing you money through power and hardware depreciation.  In our ?aaS solution we have a pool of web servers that get dynamically allocated depending on the number of requests coming through and tyhe load on the other servers.  In addition to this we can also clone our database servers and dynamically pool them too so as to avoid a bottleneck if we get super busy and the database server can't keep up with the sheer number of requests coming from all the Apache servers.

One last note that is worth mentioning:

It's not a trivial task to move to ?aaS or to adopt the SOA model.  It requires major changes to the structure of your IT department and means you lose control of at least some of your IT services.  This affects your ability to innovate.  Now innovation is important to me - I'm an Englishman.  More innovation has emerged from the garden sheds of Britain than the whole of the United States Universities and Silicon Valley!  Necessity is the mother of of invention. So, migrating to a ?aaS solution isn't straightforward.
If you want to go back to a On-Premise solution, it's a fucking pain in the arse - as some companies are finding out when their Cloud-based solution doesn't work properly, is not suited as promised, or is just laggy and unfriendly to use.  Hopefully you've still got some hardware left - you didn't throw it all out, and hopefully you've still got the details of all the people that you made redundant last week.  One thing is for certain - it's much easier to outsource than it is to bring back In-House.