Everything as a Service

As the benefits of cloud computing have started to become fully realised we have seen the birth of the As-a-Service model.

Software as a Service (Saas), Platform as a Service (Pass), Infrastructure as a Service (IaaS).

This combined with the birth of the DevOps mentality has lead to a shift in how we approach the provision of the services and functionality that we always require on any new project.

While each variant of this approach has differences in the degree to which you are involved in the detail all carry similar benefits compared to the traditional do-it-yourself attitude.

Details as a Service

While many of us may take enormous pride in managing and maintaining boxes and servers ultimately the amount of effort required to do this is often out of the proportion with the value derived.

Many of us will also have spent many frustrating hours dealing with an issue related to a Java install, a file system problem or a connectivity issue. We aren't in the business of maintaining servers but it is a necessary evil to have a functioning software delivery pipeline.

As-a-Service enables us to abstract ourselves from this necessary yet effort draining detail and focus instead on the business of delivering value to our customers via deploying software to these servers.

By taking advantage of an army of people dedicated to keeping our servers up and running we gain reliability while reducing to almost zero our effort on these day to day activities.

Expertise as a Service

Building and deploying software involves many different tasks, each with there own skillsets, as we become more experienced we will gain a certain level of skill in all these areas but it is unlikely we could ever call ourselves experts in all of them, we are also unlikely to be able to dedicate enough time to achieving that level of proficiency across the board.

We therefore do the best we can.

The functionality delivered via As-a-Service is backed by experts in their field, people who have amassed expert knowledge in the service they are offering that it would be impossible or at least impractical for us to attain.

This engineers a situation where we are essentially filling our team with experts in every aspect of delivery amounting to years and years of experience being added to our team in specific technologies, domains and functionalities.

Compared to this there is no benefit in developing these systems in house, while it may be fun we cannot hope to improve on what is delivered by experts employed to achieve excellence.

Availability as a Service

When we construct infrastructure for use in deploying and hosting our code there is generally an on-going cost to its availability, maintenance and provisioning.

This cost is usually not in line with our utilisation of the infrastructure, although it will rapidly increase whenever that infrastructure is down for what ever reason.

As-a-Service in most cases is like any other product or service you may buy with it being charged based on your usage.

This can obviously lead to cost savings for the services we need to be available but only use infrequently, but the other consequence is that we have a virtually unlimited supply of services where are need scales with the amount of delivery we are trying to achieve.

As an example, when provisioning our own build system we are likely to be faced with a choice of imposing a cap on the amount of throughput our developers can achieve or hugely over provisioning at great cost.

An As-a-Service build system can start off small but via some tweaks to settings and a proportional increase in cost can be made to achieve more. As developers get into a groove the build system can be made to adapt and ensure every last ounce of effort can be converted into the production of code.

Within software engineering we have a healthy track record of laziness, trying to use our skills and abilities to make our work lives easier.

As-a-Service is the ultimate manifestation of this attitude with the goal of ensuring developers are almost entirely focused on writing code.

While we may be capable of doing or learning to do all these tasks the question you have to ask yourself is would that add any value.

The emergence of several major cloud providers and the competition starting to grow between them means the answer to that is almost certainly no.    

Assurance of Quality

Its a truth many software engineers have a difficult time accepting, but all software no matter who produces it, usually has bugs, defects or doesn't quite meet requirements.

Once that fact of development has been acknowledged then the need to have some level of quality assurance is undeniable.

The traditional model encourages a left to right approach where coding is completed, code is tested, code is shipped.

This "throw it over the fence" mentality is inefficient and thankfully we have developed modern techniques to ensure quality isn't an after thought.

Shift Left and Automate

The ideal situation to be in is that defects never make it into a code base, they are if you pardon the pun stopped at source.

Realistically this will never be the case, but if we can move much of our quality assurance nearer to the point that the code is written we will realise huge efficiencies in producing effective working code.

This can be achieved in two ways, by introducing more automation and by having a slick and quick deployment pipeline.

Unit testing, functional testing, integration testing, we have many techniques at our disposal to very quickly verify if changes to our code base have had a negative impact in its effectiveness to perform its intended task.

By ensuring our code can be quickly deployed to the environment it is designed to operate in we can create short feedback loops to identify and address any regressions.

Whether this be by quickly making new versions of code available to a test team or by employing UI automation to validate the continued operation of our key journeys, the quicker issues can be identified the quicker they can be fixed.

Break Things

The advantage of automating and streamlining the testing of the routine is that it releases the valuable resource of test teams to focus on more abstract testing of our system.

The main purpose of this testing should be to break and destroy.

By taking the use of our system to extremes we can uncover inefficiencies or flaws in logic that otherwise would be difficult to find.

A common problem when testing software is the relatively limited spectrum of use we are exposing it to. Often a defect that we may think of as relatively obscure may actually be produced hundreds or thousands of times once its out in the field being used by a large user base.

By actively trying to break things we focusing our attention on the problems and issues that are most likely to affect people.

This destructive approach may take may forms but the important thing is not to concentrate on validation of correct operation but instead employ a machiavellian approach to try and cause chaos.

Test in the Field

Even when we implement all the methods and techniques available to us to enforce quality some problems are still going to make it through the net into production.

Because of this unescapable fact it is important we have an effective strategy to properly instrument our application to report back valuable diagnostic information, both when things are working and when there not.

Whilst it is not a sin to ship a defect, it is at least negligent to not have the ability to detect the effect on users.

Our software should be like a machine we are constantly monitoring and inspecting, whether it be out and out bugs or simply measuring a decline in performance it is vital to pay attention to what is going on out there in the field.

As well as creating a feedback loop to improve your system, analysing how people are using your software will also provide great insight into the direction it should be going in.

As we progress as an industry its important we develop and improve all aspects of software development and that includes how we test and validate the code we produce.

Innovation in this area will bring great rewards and help you stand out from the crowd.

Accept that defects and bugs are a fact of life and develop a strategy to seek and destroy as many as possible, also realise that its everyones responsibility to play a part in achieving this as we all bring different skills to the table.