Building Leaner Applications using Utility As a Service

Utilities as a Service is an emerging paradigm that is carving its place in the cloud provisioning models. In this talk, we explain what utility services are and how they can help you build leaner and more scalable applications. Furthermore, we present the current challenges in adopting utility services and finally explain how ApyHub aims to solve these challenges.

Know about ApyHub: https://apyhub.com

Transcript

1. Utilities as a Service Building leaner applications using
2. My life hovers around Code, Community & Content at ApyHub Developer Advocate Say me 󰗛 @iamspathan
3. Agenda Let’s define utilities Let’s look at how we handle them now Are utilities causing your applications to be obese? Lean applications using Utilities as a Service What’s the catch? And what should we do about it? How does the road look ahead?
4. Defining Utilities • We all use utilities in our applications, but the definition is very fuzzy • There is a range of functionalities that we classify as “utilities” Generation (e.g: invoices, thumbnails) Validations (e.g: validation of an email, tax numbers.. ) Conversions (e.g: transformations, conversions) • At the end, utilities are essential and are used at varying levels of frequency within an application
5. How are we handling it now? BUILD YOURSELF EXTERNAL LIBRARIES • TIME CONSUMING • MAINTENANCE COSTS • TECH STACK LIMITATIONS • UNMAINTAINED / ABANDONED PROJECTS Embedding Utilities inside your application (microservices)
6. Monolith vs Microservices
7. Monolith vs Microservices • Monolith : An application that is bundled as one application and requires heavy servers – over provisioning and thus sub optimal resource utilization • Microservices: Where large applications are decomposed into several services each running on their own and scale independently of each other
8. { bloated microservices }
9. The problems of embedding utilities Bloated Code Base Larger deployable units More resources to run Without embedded Utilities With embedded Utilities
10. Powering the bloat - the microservices way Let’s consider an example of a payments microservice that is also responsible for generating pdf invoices Assume that the pdf invoice generation is an atomic operation Since it is an atomic operation, we cannot expect horizontal scaling to address this issue 0.5 vCPU, 0.5 GB Memory 1 vCPU, 1 GB Memory 1 vCPU, 2 GB Memory 50 line items + descriptions + thumbnails 100 line items + descriptions + thumbnails 500 line items + descriptions + thumbnails
11. Bloated microservices For a microservice, the two key elements that we need to address are: - Scope : what will the microservice be responsible for - Sizing : what resources do we assign to the microservice As shown in the previous example, scoping affects sizing If the payments microservice is also responsible for generating pdf invoices, it needs to be sized according to the max items within an invoice and other elements that will be included in the invoice. Even if the volume of such large invoices is low, we still need to size the microservice according to the higher threshold it should support Essentially that would imply that we are overprovisioning the resources which will be mostly idle for majority of the time - entering the same space as we were complaining about monoliths And of course, it multiples the costs. 1 vCPU, 2 GB Memory
12. { lean microservices }
13. So how can we keep the microservices lean? BUILD YOURSELF EXTERNAL LIBRARIES EXTERNAL SERVICES
14. lean microservices Let’s go back to the same example as before - a payments processing microservice No matter if the invoice contains 50, 100, 500 or more - the service doesn’t need to be vertically scaled It just passes the necessary information to an external service which generates the invoice and returns the generated document 0.5 vCPU, 0.5 GB Memory 50, 100 or 500 line items + descriptions + thumbnails Utility as a Service
15. any downsides of using utility services? - Fragmented - Several providers offering a very small niche of utility services (like document conversion or email verification etc) - End up subscribing to multiple service providers - Increased Cost & Time - Overtime, these costs add up - might not be as much as running it yourself on production - but still it will add up to significant cost - Different integration formats - some could be using RESTFul APIs, some using GraphQL and so on - costing time - Suboptimal Subscription Utilization - You do not use your subscription evenly across all services (some months maybe you are using one service more than the other) - Administration & Compliance Issues - When you send your data to several providers who might be offering their service from different geographical regions it will be complex to prove compliance - Managing subscription and monitoring usage across several services will be a huge hassle overtime
16. { is there a way out? }
17. Utility Catalogs - Utility catalogs are emerging that offer: - Unified Catalog of utilities - Single Subscription for the entire catalog - Utilities Operated, maintained and monitored by a single provider - Standard integration format
18. { so where to find them? }
19. ApyHub to the rescue
20. { does apyhub help you in optimizing your development time & cost ? }
21. Yes, It does :-) 1. 60% of the development time spent. a. Standard but Flexible Integrations. 2. Scales seamlessly a. No need to worry about operational cost. b. Management and Monitoring. 3. Extremely Fast a. Our services are built using lightweight frameworks b. Optimized to have the best response times, and the lowest latency possible
22. SDKs { Available at github.com/apyhub }
23. Guidelines 1. The projects should be, ideally, deployed in an environment which is accessible to the reviewers. 2. Calling APIs from the front end will lead to a CORS error - ApyHub does not support frontend apps directly calling our APIs due to security concerns. 3. Hence, the API calls should be made from a backend server of your tech stack. ( NodeJS, Go, Java etc.) 4. You can find a sample backend server. (in hacker guide). 5. If you are still facing an issue, please connect with our representative.
24. { we would love to know your feedback } apyhub.com Use APYDEVS code while registering to receive 5,00,000 Atoms (close to additional 5,00,000 API requests)
25. 1. Join ApyHub Discord using QR Code. 2. Follow @apyhub on Twitter 3. Take a picture with ApyHub Booth/Standees And tweet your LOVE about APIs in caption Tags: @apyhub @hackthisfall #hackthisfall #apyhub