Life can be hard for developers and engineers working in large enterprises. Whatever you are working on, there are usually many constraints, stakeholders to check with, and interoperability requirements to legacy systems that must be delivered somehow. So how can all this help you as a web developer, engineer, or IT manager in a large international firm?
More like a minefield than a brownfield, as some would say. In such an environment, developers, engineers, managers, and users alike appreciate solutions that “just work” and have a high degree of compatibility no matter how mixed your tech stack is. All the latest platforms and languages are supported.
What is serverless architecture about?
There is a strong marketing pull on products that sell services and functions “in the cloud.” To enterprise users that means that the service is neither hosted on their own premises (on-prem) nor in a controlled data center.
Though no service can run without a server, the term serverless architecture merely means that the technology-focused teams can deploy their backend in a third-party environment and not need to bother about the hardware specs, running the tins, or procurement and change processes. This kind of setup is also known as BaaS, (Backend as a Service) or simply as “cloud computing.”
How does that help you?
The business demands rapid actions, and the users want updates, but often there are strict processes and workflows in place that can delay shipping releases and content. Even if you take care of all the planning and preparations diligently, there might be other showstoppers that slow you down. You’re not entirely happy with the performance yourself, because you know it could be better. You can’t change the whole world, but you certainly can improve some aspects of your technical environment.
When you leverage content infrastructure, you can combine the best of the two worlds of agile development and modern content publishing. Solutions should be designed as an API-first platform in the cloud with a strong focus on compatibility with various software shipping methods and programming languages. For your operations, this means less struggle and more shipping.
All this compatibility means that you can easily integrate with other existing services via webhooks and different kinds of triggers. Creators can stay in their world and prepare content the way they want. They only need this one point of entry to edit content anywhere. No matter if editors and creatives are going to publish to websites, smartphone apps, games, IoT systems, or even VR environments, they can do all that from one tool. Less stress for the content creators also means less stress for you.
The startup inside the enterprise
Intrapreneurs and product managers listen up: Often new projects are taking off in large companies, and whether or not the product is meant to be available only to the internals or also to the public, such endeavors are similar to running a new startup. You build a pilot with the team, tinker with it, do some user acceptance testing (UAT), quality assurance (QA), and then hope it will get popular and grow over time.
To make sure you can scale any kind of growth in user numbers and the complexity of functions, it’s essential to have sufficient resources to run the services. Suppose you are not paying attention when picking your future infrastructure and content management solution. In that case, you will continuously need to monitor, measure and report the delivered performance against the business demands and add new infrastructure components every now and then to cope with the growth.
You could call this the “pain of success.” Something like this can occur when you don’t plan for an upscaling strategy. If you found the right vendor for your business case, you can fully concentrate on improving your product without the bitter taste of procuring new servers occasionally. To startups, this doesn’t sound like a big issue but deploying servers can take months in an enterprise.
The absolute total cost of ownership?
All these scaling advantages are also valid for redundancy and fail-over scenarios. In the enterprise world, you usually need to have a fully-fledged setup for disaster recovery (DR) for compliance. This means that every server you need to provide your service to your users will need to have a backup in case the primary instance fails in some way.
For the total cost of ownership (TCO) this often means purchasing and deploying twice the infrastructure hardware components that you’d actually need, for compliance’s sake and of course to cover availability aspects of your service level agreement (SLA). Correspondingly, this increases the complexity of maintaining these components for the engineers and support staff. On top of that, you build a UAT and DEV environment for testing and development activities. Managing a product should be more straightforward than that, right?
If you source these worries to a third-party cloud provider, you often have a good return on investment and reach the break-even point relatively quickly if you take all costs into account. Plus, you get the bonus that the product owner has a better sleep at night along with everybody else on the team who cares about the product.
Now, is it really time to unplug?
If any of those points sound familiar to you, and I’m sure you know what I mean, you might be wondering if it is indeed now the time to unplug the servers, thrash the tins and go all-in on running your content as a service through the cloud. It sure sounds tempting, does it not?
There’s no single right solution for all services out there, but if you want to start looking for content solutions, you can have a look at providers such as Simple [A], dotCMS, WordPress VIP, Netlify CMS, or Prismic. They come with different options and pricing so make sure you capture your requirements first before you compare the vendors to save yourself some time.
I hope you found this a little helpful and I wish you good luck with building a sustainable, high-availability environment that you can scale without worries, as you deserve it.
Photo credit: Tristan Schmurr / Andrew Eland
