Why ‘Utility as a Service’ Is a Critical Component of the Developer Toolset
Everyday, a developer's life revolves around designing and building applications that create value to different audiences. As a developer, at some point in the development lifecycle, while building your application you will face the need to use one or more common components or software utilities in order to deliver the value and functionality that your application promises.
These utilities could be core to your app's business domain (e.g VAT calculation in an e-commerce platform) or essential to the smooth functioning of your application (like country lists, file conversions or image processing).
Say for instance that you’re building an app/website where users need to select the country code before entering their phone number when registering or checking out. And you also want to send an invoice (in PDF) to the user after they check out, and would like to watermark this invoice and send it to the user by email. You can probably think of many similar examples of utilities that you have used in your applications.
In order to do so, as a developer you basically have three options: you could decide to build these utilities in-house, you could go with finding and making use of external utility libraries that can be directly embedded in your code/application, or finally you could opt to use external utility services.
There are, of course, pros and cons to all sides:
Building your own software utilities will most likely mean more control over the code, the utility itself, and the data. From a compliance perspective, this approach also seems to be the most simple and straightforward. The downside? Bloated applications, high maintenance costs, and of course more resource needs (memory and compute).
Using external libraries has similar benefits when it comes to control over the data being processed and stored. On top of that, these libraries are relatively easy to integrate into the code and the performance is optimal as the library runs natively within the application. The downside? Bloated applications seem to be the main problem here as well. Moreover, there is some lack of flexibility as the libraries are tied to specific tech stacks; libraries can also be untrustworthy, and are resource intensive Finally, introducing a new library can be challenging for organizations with strong policies for compliance.
Using external utility services is the option that usually leads to leaner applications that only contain the core business logic, letting the rest be handled, managed and maintained by external parties (the service providers). Since these service providers are entities and not communities, the trust factor here is very high and developers can be certain that their applications can scale, upgrade and fit their growing needs. The downside? Applications usually need multiple services and have to rely on different service providers which results in managing multiple subscriptions and integration requirements- costs quickly add up.
Here’s a quick recap of the pros and cons of each:
Build yourself
+
• Complete control over the implementation of the utility • Control over the data being processed and stored • Ease of compliance
-
• Bloats the application • Requires more resources - compute and memory • Time consuming to build these utilities from scratch • Difficult to maintain • Cost time, money and resources • Takes attention away from the core application you’re building
Utility library
+
• Easy to incorporate into existing code base • Control over the data being processed and stored • Better performance since it runs natively along with the application
-
• Bloats the application • Libraries are tied to a specific technology stack • Depending on the utility, additional memory and compute resources need to be allocated • Upgrading utility libraries requires redeployment of the application • In some cases, untrusted sources for these libraries • Developers could also be building their internal libraries but then they have to maintain them • No guarantee for maintenance and support of these libraries • Compliance issues for larger organizations to vet every library being used
Utility service
+
• Lean applications containing only the core business logic • Scaling of utilities handled by the service provider • Maintenance by the service provider • Updates to utilities require no redeployments of the application • Utility services are typically managed by an entity rather than maintained by a community, thus addressing the concerns over unknown sources • Choose plans that meet their requirements and upgrade seamlessly as the usage grows
-
• Multiple service providers for utilities • Managing multiple vendors • Subscriptions with each provider for a small set of utilities - costs can quickly add up • Integrations not uniform across these utility services • Enterprise or consumers data spread across multiple providers, potentially in different jurisdictions • Different terms & policies across these service providers • Difficult to monitor the usage across all these different services • Developers, could choose to build and launch their internal utility services, but then they have to maintain and manage them
The need for agility and flexibility is leading many organizations (as well as developers, engineering managers etc.) to opt for the last (utility) service route.
‘Utility as a service’ is slowly but steadily claiming its unique place in the developer toolset, as a model for organizing, connecting and consuming external services within an application.
This model, as shown above, comes with its own limitations, and ultimately slows down or takes attention away from core development.
So what’s the solution? A central point, a hub or platform where developers could discover software utilities in different categories which coexist under a single subscription, as a service.
What is your experience? How do you incorporate utilities in your app?
Nikolas
Top comments (0)