Building and running SaaS with Devops

The primary objective of a web application is to address the requirements of the end user which requires a whole team to be working effectively together, from sales and marketing through development and delivery to customer support and maintenance. I'm going to focus on a few small areas of the development and delivery parts here, although to be clear these don't exist in isolation - without the other teams there would be no client in the first place!

Making a web application fit for purpose, performant and highly available means striking a balance between these three areas. For example, a great application that isn't available when user needs it is no good and a fast application that's buggy and hasn't been updated for 6 months is of equally little value.

Architecture and strategy

A web application must be written in such a way that it can be run effectively on it's target production hosting platform. It's relatively easy to go build a monolithic application, but if this can't be easily deployed, scaled and secured then the overall effectiveness of the project will be impacted, although it's also important to not go nuts with architecture early on and design a system that's so complicated that development times are vastly extended, placing the whole project at risk. Often a monolithic application written using solid encapsulation principles can be split into services later on with relatively little effort; the key to this is to maintain good discipline and clean code early on, and then break it out later on when the project has good momentum.

Deployment methodology

A good code architecture will ensure that functional units are encapsulated, allowing chunks to be updated with little or no impact on other parts of the application. Coupled with a solid testing approach, this will allow small changes to the application to be deployed on a regular basis. The underlying principle is ensuring that the "unit of change" is kept small and that deployments are fast, small and easy. Fast, small and easy deployments reduce the risk of outages related to the release of new code, which positively impacts the stability to the production platform.  Fast, low-risk deployments then lead to a high deployment cadence, which in turn means that any bugs that slip through can be quickly and easily resolved, further increasing deployment cadence. Fast feature release and bug fixes are highly desirable to end users, leading to better platform adoption. This approach will often complement agile development methodologies.

Deployments should be automated early on in the project lifecycle, and used and tested regularly. As code architecture increases in complexity, deployment approach will need to evolve to match. Don't let the perfect be the enemy of good here - it's better to be pragmatic and have a working deployment that can be relied upon, and plan to update it as you go. You may have occasional failed deployments, but in the bigger picture it's better to accept that this is going to happen and roll with it. Robust deployment processes built on best practice should be easy to fix, and it's key that they should support the project deployment cadence. While users may occasionally complain, this will be vastly outweighed by their appreciation of fast delivery of new features and fixes. Obviously some of the risk here can be mitigated with things like blue-green deployment, time-of-day planning and planned outage windows, and this approach isn't appropriate for super critical platforms.

Monitoring

Monitoring and alerting are obvious activities that must be conducted on a production platform, but their value can be vastly increased by ensuring that appropriate metrics are captured. Effective APM monitoring should be able to lead devops/development teams quickly to the root cause of an issue for fast remediation and fix deployment. For example, classic ops monitoring can tell you that a web node has gone offline or run out of memory, but not why. Tools like NewRelic can show specifically what method/class is consuming resources and make this immediately available to development teams.