Being Nimble: Balancing Development and Using Services
Products “as a Service” have continued to become more prevalent, especially in the technology related industries. The adoption rate for Software as a Service (SaaS) has steadily increased, giving it a strong foothold in the cloud computing space. It is so commonplace now, that most people hardly differentiate between the traditional software products and SaaS; and they certainly don’t hesitate to use the SaaS products. Many companies have now also become more interested in the Platform as a Service (PaaS) and Infrastructure as a Service (IaaS) offerings, such as those provided by AWS. Slightly newer additions to the mix include Data Warehouse as a Service (DWaaS) as well as many others. You have quite the number of options, from individual component to fully managed solutions.
These services are certainly not a replacement for custom development, but I do think they are sometimes overlooked (or underestimated) a bit too quickly. Many technology organizations still tend to gravitate toward a “build your own” approach.
Why ?
The benefits of choosing a service-based solution should be enticing teams to more readily embrace cloud computing. At Enova, we work to find the right balance between building what is core to our business and using best-in-class services from the industry. There are many benefits to this.
It saves you money and keeps you focused
Most that are familiar with these Products as a Service already understand the benefits, many of which lead back to money. Obviously you are reducing capital expenses in exchange for variable expenses that more closely track your precise needs. You are benefiting from economies of scale, both in terms of the virtual resources and in terms of expertise. Even if your tech team could build it better than Amazon, is that task at the core of your business? Is that how your business will make the most money?
The cost debate is always an interesting one, as everyone has their own slant on calculating the TCO for a given implementation. But it is hard to compete with solutions that are built within multitenant environments and that effectively share the costs associated with hardware, software and maintenance. Every time you leverage a service, you reduce the number of responsibilities your team must assume. And every responsibility that is brought in house has a corresponding cost relating to recruiting, hiring, training and retaining those (people) resources that are necessary to support that responsibility. A company may have some really great people who can be stretched to cover multiple responsibilities, but wouldn’t their time be better spent helping the business differentiate itself from the competition?
It saves you time
When I think about MVP and time to market, I immediately focus on the speed and ease with which service-based resources can be created by developers to bring systems to life more quickly. The faster they can spin up the required infrastructure or related resources, the sooner that they can proceed with development — and the sooner they can begin to form a working solution that is production ready. The more traditional approaches simply can not provide the same type of turnaround time. It is almost like using a programming language but not leveraging its standard libraries. Why would you start from scratch and rebuild the common components each time you start a project? We all like to build things using our favorite tools and building blocks. But now, our building blocks have become much larger (in the form of services), and we can significantly reduce construction time if we use them wisely.
You are not over-provisioning
Often teams are tasked with building solutions that scale, and the scalability requirement adds greatly to the complexity. In addition, the ability to scale (up) is often not good enough. To be cost-effective, a system often needs to be elastic; it needs to be able to scale both up and down. Scalability and Elasticity are areas where service-based solutions really shine. With a service-based solution, you are often starting with production quality components that already address the complexity of scale. And they are built to be elastic, with a pay-as-you-go model.
When employing more traditional methods, in order to support a solution that must scale, you often need to “project” the maximum load to be imposed on the system; and not just the maximum load for today, but the maximum load within the next 6 months to a year. Then you need to purchase, install, configure (and start paying for) that hardware/software/etc. You are basically forced to over-provision your infrastructure from the very start. This is not very practical or cost-effective. It’s just like when your cell phone provider says you need to guess how many GBs of data you might use next month! You are not really estimating for a single month — you are actually trying to forecast your maximum usage for the next few months. For me, with my family of 6, I can certainly relate to this problem. With one son in college, who seems to never be within the campus wifi range — and who burns through more data than the other 5 of us combined — there is no surefire way to know what kind of pressure might be exerted on our cell phone data plan each month. Luckily, you are not forced to do this with your IT infrastructure. With a service-based solution, there is no need to over-provision. You can scale up and down on the fly, providing more resources when they are needed and saving money when they are not.
Recent trials and tribulations:
On a previous project, I was evaluating a proprietary NoSQL data store. We needed a large, powerful distributed database that could handle a significant workload. The DBMS under evaluation seemed very impressive…on paper. But how do you evaluate such a solution and truly put it to the test without appropriate hardware? How do you make sure it fits your use-cases? Since the proof is always in the pudding, we had to see for ourselves. We wanted to push the system and see its limitations first hand (now). Leveraging existing services (particularly infrastructure) would be essential for the initial POC as well as a vital component for a fully-scalable (and elastic) production implementation.
In a subsequent blog post, I will cover that experience and the very valuable lessons learned. Suffice to say that many dollars were spent that year, but many more were also saved by taking a service-based approach for the solution. We had the ability to rapidly prototype, fail fast and course-correct as needed. None of the vendor’s claims about their product’s performance or scalability were taken at face value. The ability to verify if the proprietary DBMS would (or would not) scale for our use cases was invaluable.