How to best use of serverless technology in a microservices environment ?

It is straightforward that server less technology and micro service architecture are rise in popularity to build great innovative data products. In today’s conversation let us try answering together how to best use of the server less technology in a micro services environment by leveraging some of the pointers on migrating to server less environment using FaaS (Function as a Service) service model. 

Now this comes with two questions whether to use something new server less environment or to do or migrate micro service to server less; which would be low hanging fruit for us.Then we should choose to migrate the traditional deployed micro service architecture to the server less technology. 

The top 5 areas we should look before we migrate to serverless from microservices:

1. Data - For an example if the siloed databases are leveraged for the data application then we can able to migrate to RDS like DynamoDB and others. But challenges we have change the semantics & behavior, so we have to change the programs to arrive at the same type of data type.
2. Messaging - Message system is another area where we can look at the service space to migrate to the server less.  For an example RabitMQ used to communicate asynchronous between services and the downstream systems can consumed by Amazon Kinesis. This brings the whole load of heavy lifting to platform server less and it works best when we use brokers in simple ways.
3. Moving to Function - Lift and Shift code base to a function. It relies on a single entry point and it will offload a lot of infra management which would be quick win for us.
4. Decompose to Functions - We needs to think the data angel with easier to right-size a function. 
5. Pre-condition -  The log aggregation, automation, and tractability are must features we needs to look into when we moving to FaaS from micro service environment. 

Top 7 Concerns in Serverless with Solutions:

1.Vendor Lock-in - Don’t think about lock-in, just think about the migration cost. We expect the Cloud as utility, but actually they are not. Also, it is good to be locked locked-in in good place, and when in comes to mixing vendors, each platform needs deep skills. When we think about vendor lock-in, then we need to think in the perspective of pay now or pay later.

It is a trade off and below depicts us better with grid, hence don;t worry about lock- in, think about migration cost.

2. Security - Basically we have concerns on the multi tenant execution. All we are leveraging some kind of technology based out of containers using some thing like docker under the hood. The alarm raised in the perspective of how the containers are isolated from the virtual machine isolation ? Now the question to ask yourself is the security best, or we have enough  security ? Below could be one of the best options to solve our Security concern in the server less technology by leveraging Hyper-V container.

Also, we have options like  Synk, where it helps to continually finds and fixes vulnerabilities in our dependencies. Hence, we are better place now with security in the FAAS based solution. 

3. Local Execution - In general we have concerns on the we don’t have local environment to test and quickly prototype it, but it is not true; we have many options to achieve the local executions in place. We the developers love the quick fast life cycle develop to test, so for an example test driven development is super great. Do we have isolated test environments ? Something from Amazon we have SAM Local which is AWS CLI tool for managing Serverless application written with AWS Serverless Application Code (SAM). It can be used to test function locally. Also, in Azure we have features of Azure Functions Local Debugging options, to test our function locally. Even we have local emulation with DynamoDB, Cosmos DB, Cloud Bigtable. Cloud Datastore for BAAS, and waiting for the Cloud Spanner. And please do remember, local emulation is not equal to running on the platform.  

4. Troubleshooting  - When we wrote the function, it would be running on their other platform and infrature, and concerns here is how do we get the information we needed ?  Do we have troubleshooting tools ? In microservice environment we have perimeter monitoring so with the help of log aggregation tool, we can aggregate the logs. So at last, all logs will be in one place. But functions are ephemeral, but luckily we have tools like GCP Stackdriver, and AWS Cloudwatch to solve this problem. Also all main vendors collect metrics, hence metrics will be default, but it can be collected. Few of the other tools can be leveraged such as honeycomb, Prometheus, Humio, and logstash. 

5. Frameworks - We discussed above with how the functions makes our life easier. But the simple stuff is not always easy, conceptually easy but execution and implementation would be super hard. We have loads and loads of options are there like SPARTA a go framework, ZAPPA serverless python framework, APEX, along with these we have another framework called Serverless framework, yes the framework name itself is called Serverless which provides automatic scaling, agnostic vendor with rapid deployment possibilities. Definitely last one more ZEIT, should be explored in the stack of serverless framework.

6. Performance - Always we have concerns about the functions to launch and  performance variability. Memory configuration for the function is tricky, which needs to be calibrated better, and we have few options for the same. And we have to tweak the memory, we thought this was serverless. And the reality is when we adopt someone else abstraction the we have to accept that we may lose control of something. Also, we should be aligned with that performance is directly proportional to different run times and also it depends on the memory size. So, understand what performance your applications is needed, and how you want it to scale up or down, then investigate whether it is in out of box or not by the vendor. If we need fine control, then you need to do it by yourself. 

7. Resilience - The resilience challenges can be handled with the circuit breaker  with below approach. But we should look in to about hybrid apps.Another way we can able to leverage patter of circuit breakers approach. Circuit breakers rely on maintaining per-client state across requests. For hybrid systems, consider our hand-off points between server less and non-serverless technologies. 

To conclude the server less technology is supernova in the cloud ecosystem with right tools and right approach.

Happy Serverless (FAAS) !