Part 1: Fish Taco, Taqueria and Dapr
Nothing says San Diego like palm trees and sandy beaches from the nature reserve in La Jolla to Mission Bay and Pacific Beach; however, for foodies like myself, there are also fish tacos and taquerias. What do fish tacos and taquerias have in common with Dapr? I will come to that in a bit, but first some background context for the comparison.
When I attended VSLive San Diego 2019, I was inspired by the durable function offering on Microsoft’s Azure platform and I was able to get an MVP application from development to production in a few weekends. I was also fortunate to be able to attend VSLive San Diego 2022 a few weeks ago and sit in a workshop and presentation on Dapr. I was inspired by the technology while trying to get the various parts of the Dapr workshop together.
More often than not most of the business applications I worked on are concerned with the automation and processing of data to provide some business end goal, let's say making fish tacos for end users.
Platforms such as Dapr are designed to not only achieve some business goal (i.e making fish tacos for end users) but also to create a template for the process so that you can not only get fish tacos but build a taqueria.
Contemplating that thought, I decided to convert the MVP application I created in 2019 using durable functions to Dapr. In terms of business application, converting to Dapr for the MVP app is not cost-effective for the amount of traffic that the application gets as I will be trading the cost of orchestration of services that are currently handled singularly by durable function to individual VM(s).
In terms of hosting cost, purely looking at the numbers** it makes sense to consider containerizing if the amount of requests coming to the durable function exceeds 16 million requests per month.
Even though the conversion doesn’t make business sense, it is a great experience to try out new technology. There are also other reasons for converting the application such as the need to templatize the business application and share it across a team of developers. Durable functions are very effective in processing business requirements that don’t require functions to be in a constant hot state. Various bindings such as ServiceBus and Azure storage also make the durable function very attractive for hosting highly scalable services.
Dapr uses service-agnostic patterns to address common issues faced by distributed applications.
Usually it requires a considerable effort to migrate sub-components of applications that are hosted in the cloud as there are often design decisions made that are tightly coupled with the implementation of a cloud solution.
Moving from, say, Redis to RabbitMq for brokering messages might, in some cases, require actual code changes vs configuration updates.
Dapr helps with the process by abstracting the way data is processed and communicated between processes such that a cloud solution could use more configuration changes vs code changes to swap sub-components of a cloud solution.
Here is a rough draft of what conversion looked like for the MVP application.
- Mapping out the current orchestrator pattern
2) Grouping shared business together. Even though I am grouping individual processes (methods) by their functionality (e.g. these methods are tied to users etc) I could also group the processes by scaling needs. Services that need to scale together can be coupled together in one application)
3) Start creating the containers (continued to Part II: Fish Taco, Taqueria, and Dapr)
** Based on Az function consumption plan and hosting containers on AKS cluster hosted in Linux VMS in azure.
Image credits:
Dapr.io
Clay Banks
The Nix Company
