This article expands on "7 Guiding Principles for Serverless Systems", exploring the second guiding principle which is to leverage services, not code. If I had a mantra for this principle it's, "Your business doesn't differentiate itself on what everyone else does, it differentiates on what everyone else doesn't do". While this might be a fairly straightforward concept, old habits of solving problems yourself can be hard to break. This article will investigate how to take this high level principle and elaborate on how to understand it better to make its application easier.
How to think about services and their value
We can break all architectures down into components which fall into four general categories:
Foundational Architecture: Hard Drives, CPUs, Operating System, Programming Language, Runtimes, etc
Common System Architecture: Active Directory, S3, Step Functions, etc
Industry Architecture: Database Schemas, Industry specific billing systems, etc.
Organization Specific Architectures: Your company's website, custom algorithms, customized database schemas, etc.
These form the "Architecture Continuum" and each one gets more specific as you progress through them. The goal of the architecture continuum is to understand what type of problem and architecture you're trying to solve for. For example, if your team is solving a generic workflow problem, writing a custom solution probably shouldn't be where you start from a planning perspective. If your team is trying to solve a problem that only your business has, looking for solutions from third parties might be an exercise in futility.
As we look at the second principle, we're really trying to focus on solving the first three categories in the architecture continuum by using third parties rather than your company's employee's time. We're at a point globally where a lot of common problem are being solved by third parties, such as AWS, Azure, IBM, as well as a ton of startups and mid-sized companies. At the same time, most traditional systems have a ton of common logic and the same mistakes, which recreate what services can provide. This is really where we can start looking at serverless systems as a viable option. What if your serverless system only had to have organizational specific aspects and the connective bits between services? You'd end up with a much smaller code base which requires less testing, is more stable and can adapt more easily to more complex problems. The resulting impact is smaller teams, more business impacting capabilities, increased security, and lower overall cost for IT.
Using Services Example
Let's say that your business had a workflow it went through when a call came into your call center. In that workflow, the call center worker needed to know who the customer was, find their account, if they had an existing service ticket open have that available, flow through a common set of questions and while those questions where being asked, the backend system would run different diagnostic commands based on the answers. This would probably be a fairly complex bit of software if you were to write it for your company.
Using principle two, we start with focusing on getting services for foundational and common system architectures. Call Center Management Systems are fairly common in today's world, as are customer relationship management services (CRMs). Finding two of these services which work together can solve getting customer information, service history and even customer workflows built out for you. This means that most of your system can be common components which are well understood and less your team has to figure out which you can purchase or subscribe. From here, your team just needs to build out the integrations to your diagnostic tests.
The result reduces the need for a deep understanding of systems that aren't specific to your company, leaving your team's valuable time spent on higher business value objectives. On the financial side, the team size needed to build and maintain a call center management system and CRM would dwarf the cost to purchase or subscribe, especially since you'd have to cover the cost of stabilizing, fixing bugs, creating a prioritized backlog, performing regular security scans, etc.
The side effect of managed services
Beyond accelerating development, a managed service approach to building systems also has long-term ramifications on what skill sets your company needs to develop and maintain and the predictability around your budget. With the effort to manage these two aspects reduced, it becomes possible for companies to invest more of their time in impact.
How does a service first approach impact the skill sets your company needs? There's a lot of time that goes into maintaining systems. From security monitoring, to patching, to keeping up with the latest approaches to the problem the services solve. With these aspects, your company has to hire systems engineers, security managers and specialized operations managers. This team would typically develop patching protocols, find tools to help identify vulnerabilities in operating systems, runtimes, as well as services and their dependencies. Add to this ongoing training and tools to monitor and remediate intrusions and your company's plate gets full pretty quickly.
Having a service first approach allows you to offload this effort to third-party vendors. There is still effort, but it's focused on making sure the vendor is performing best practices. The good news here is that cloud providers are making it easier for companies to ensure your vendors are doing just that, with AWS now offering automated validation of security standards that your vendors can expose to you. Your team as a result reduces the breadth of skills needed and instead focuses those funds on accelerating capabilities.
The second aspect to a service first approach is around large purchases and investments. Non-managed services require large purchase prices and licensing costs. They also require higher up front efforts around integrations into your existing systems, migration efforts and validation efforts. This all leads to high amounts of upfront planning and budgeting, which lasts for a few years then must be performed again for the next big upgrade. This creates spikes in budgets and can become less predictable when the system you use has features your team needs but requires an upgrade to get. Managed services are the flip side to this. They tend to require less budget up front, and there is still the initial integration effort which can be pricy in terms of time. The payoff comes after that point when your team and the service evolves incrementally. The service makes incremental changes which require a small amount of effort from your team every so often. This trickle of work results in your team always having access to the latest capabilities, latest integrations and keep up with competitor's capabilities. All of this comes with the third party monitoring, validating and patching security issues as well.
Making home grown solutions shared services
One question I ask is, "If what you built doesn't exist but isn't that specific to your company, does it make sense to make it open source?". There's an inherent fear when making solutions to common problems open to your competitors, others across your industry and even hackers. So why would you make a non-organizational component open source? The answer is that there are lots of people who are probably solving the same problem as you, making the same or different mistakes and ultimately everyone's systems are more vulnerable and provide just as bad an experience. If you take the risk of making your system open source, and getting others to take part, you end up with more eyes on this common system. With this approach more companies run vulnerability scans, fix bugs, and share the burden of maintaining the system. What's even better, as others contribute, they solve challenges you haven't considered yet. As your company evolves, some of these capabilities will propel your company forward faster, as the concepts had time to mature before you needed them. This also has the added benefit that there is a larger talent pool in your industry which can understand and use the tools your team uses, making hiring easier. Finally, there are third party services around security and hosted automated testing which open source projects can use for free, and cloud providers have programs that give your company free credits when you have open source projects.
Aren't our systems what make us competitive?
The problem with a closed door policy in common problems is that it's not a competitive advantage if everyone has a range of poorly designed systems resulting in a mediocre experience. Your customer's experience typically boils down to one or two things that you do your competitors don't. As an example, your customers typically are less interested in how amazing your custom sign-in process is if you're a video streaming service. By focusing less on those common shared services and patterns, you get an edge to focus on things that can really set you apart in your industry.
Conclusion
Using services can dramatically reduce your costs and focus your team's time on what sets your business apart from others. Knowing when to apply this principle can save your company a lot of time both up front and long term with maintenance, security updates and patching. Getting started with a service first approach is still a shift for most teams, and can take time. Vendors like Trek10 can help your company develop these skills faster with mentorship and support, but it's still going to be a journey.