Tuesday, March 27, 2018

Azure @ Enterprise - Functions v/s AWS Lambda

Serverless @ enterprise

Serverless is a buzzword in the software industry right now after Microservices. As with any other technology revolution, startups will jump into it and Enterprise will only be entering to Serverless slowly. Earlier the technologies would be Enterprise ready from the starting itself. But now a days it seems Enterprise support is little behind at the technology edge. 

This post is an attempt to examine the Serverless offering is ready for enterprise. Since the series is Azure @ Enterprise, lets see from the Azure side.

Cost

If we consider cost, that was not a big factor for Enterprise. They usually buy big boxes to meet their peak load and enjoy during the normal load and struggle during the heavy load. Whatever capacity planning we do there are chances that the real load differ because of  unknowns.

But with the Cloud adoption, enterprise started thinking about cost. If they had embraced 2 pizza team strategy or Microservice architecture style or devOps teams there are high chances that small teams started maintaining services / applications end to end. In order to prove their success they are forced to reduce cost in the operations. Ultimately cost becomes a factor in Enterprise.

This think enterprise to adopt Serverless or true pay per use cloud offerings. At present in Azure, Functions are the real pay per use service. Hence the title limited to Functions. Cost wise, Functions has got good score.

Versioning

The versioning might be a concern if the enterprise is using blue green deployment where the applications move to production and there might be some rollbacks required.
In Azure Functions there is no versioning concept except pulling from the source control repo. But in Amazon lambda which is the Function equivalent in Amazon cloud, there is versioning. We can have smooth version control of Functions in even in the production environment.

Security

Next factor is securing the Enterprise. There will be less chance for the Enterprise to compromise on security because something is cheap. If we take that thought to Functions, there are 2 challenges with Functions right now.

Securing external internet facing Functions

This can be done via API Gateways. There is not much challenge in that once the suitable gateway is selected. It ensure there is no DDoS, brute force, injections etc...

Securing internal Functions

There could be lot of internal services which are supposed to be exposed inside Enterprise. Normally on premise network would be protected using appropriate measures. The end points might not be visible to outside. This is the area Functions lag.
Suppose we need to have an internal Function there are 2 options. One is to setup the firewall rules. Second to host inside vNet or virtual network. Then the Functions end point will not be accessible outside.
The best way is to use vNet but the problem here is pay per use Functions don't support hosting inside vNet unless they are under AppServiceEnvironment (ASE). AppServiceEnvironment provides an isolated environment for the Enterprise to host things. But the problem with ASE is that it is highly costly. around $1200/month. The real problem is that the cost is fixed regardless of the usage. We lost everything we talked about Serverless if it is fixed billing.

Amazon Lambda

Amazon have VPC instead of vNet. It doesn't seems there is a fixed high cost if we wanted to host Lambda inside the VPC. Please note the information is obtained from google and feel free to correct. 

Some links below on Lambda and VPC

https://aws.amazon.com/premiumsupport/knowledge-center/internet-access-lambda-function/
https://aws.amazon.com/blogs/apn/why-use-aws-lambda-in-a-custom-vpc/

More differences

There are more links out there which compare Azure Function with Lambda and Cloud Functions from Google cloud.

https://cloudacademy.com/blog/microsoft-azure-functions-vs-google-cloud-functions-fight-for-serverless-cloud-domination-continues/

Tuesday, March 20, 2018

Circular relationship diagram for Microservices and Serverless architectures

Microservices is the trend for splitting large systems to individual self contained subsystems. With the advancement of Serverless offerings more and more systems are created or moving towards Microservice approach.

Is Microservice same as Serverless?

Before we go further let us clarify the difference between Microservice and Serverless. There could be some readers who thinks both are same and Serverless is more advanced. To be frank, there are fundamental differences between these two.

Microservice - It is about splitting the systems into small sub systems which are deliverable by them selves. Microservices can be hosted either in Cloud or in onpremise data centers. Microservice has to manage its own data and that data should never be touched by other systems directly.
If the system consists of couple of services and both are maintained by same team, those services doesn't necessarily be separate.

Serverless - It is about freeing the developers from worrying about underlying infrastructure. They just have to write the code and give to the hosting environment. The environment takes care from there about scaling, fault tolerance, patching etc... to maintain a promised parameters such as  predictable throughput, OS level security etc...

Problem

The problem with Microservice is the integration of Microservices. If it is single big monolith system the integration is handled by the class relationship. When we move to Microservice the complexity is moved to the service integration level from the class level. The overall complexity of the system is not changing. It would be easy when we start Microservice based system from scratch or convert existing. But it gets difficult when the count of Microservices goes beyond 50 or 100. Especially to understand their relation to each other. Who calls who and what protocol ie ie dependency. 
The technical solution for this problem is to implement Service mesh or service discovery mechanism so that we have the connection details at central place.

But how do we create a diagram to represent those relationships. If we use traditional blocks and arrows model, it will take more time to understand than the time for coding the same. So lets take another approach.

Circular Relationship Diagram

It doesn't seems that there is a standard name for a diagram which puts the entities in the edge of a circle and shows connections by drawing lines between those through the circle. As programmers lets try to generate one by code than buying a software.

D3.JS for Circular Relationship Diagram

Most of us would be familiar with the D3.JS library for charting in the browser. That library have the support for creating circular relationship diagram. Below goes one link.

http://mbostock.github.io/d3/talk/20111116/bundle.html

The above is not intended for plotting the relationship between the Microservices. But as programmers we can easily change its data to provide our Microservice relationship. The above link doesn't need any server side coding. All it needs is web server to serve HTML pages. It can be IIS, Apache or anything.

Thanks to the D3 library and author of the sample.

Other references

https://github.com/nicgirault/circosJS
https://modeling-languages.com/javascript-drawing-libraries-diagrams/

Tuesday, March 13, 2018

Uploading large files from browser to ASP.Net web server - WebSockets

Problem

Most of the applications are now web applications. When we are in browser we are in restricted area. We cannot code freely to leverage machine's full capabilities. One of the area where the limitation applies is on uploading large files which is a normal use case. Small files we can easily upload using file input control. But when the file size grows we get into trouble. 
There are so many solutions out there including third party controls. But what if we need to write one from scratch? What are the options?

Alternatives

We can use ActiveX controls which helps to unleash the potential of the machine. With the arrival of HTML5 FileAPI we have more control in the HTML itself. There are so many third parties who are making use of the same. If there is a way to use ActiveX or third party controls, the problem is solved. Else or you think the existing solutions are not enough, continue reading.

Solutions

There are many ways to upload files. Below are the principles taken on the solution approach

Principles

  • Never use ActiveX
  • Read the file without breaking the browser memory (chunking)
  • Should support up to 25GB file minimum.
  • Support scaling
There are reasons behind the principles but are not relevant at this point. Below is the first solution and that is going to be discussed in this post.

WebSockets

One of the modern way is the WebSockets. Below goes a repo which demos how the file can be read async and sync methods and send via WebSockets.

https://github.com/joymon/large-file-upload-from-browser

Feels free to surf the repo and comment. Will be adding more development notes soon.

Results

  • Using a Web Worker and FileReaderSync API seems faster than async FileReader API.

Limitations

Below goes some limits
  1. The connection has to be open. Affects scaling.
  2. Socket connection management is tedious
  3. The server is slower in reading and writing the files. Client reports it send all the data.

References

Tuesday, March 6, 2018

Azure @ Enterprise - Limits on AppServices

AppService mechanism allows free tier to host Azure WebApps. Though this has 2 min execution timeout, it is a good place to host web sites.If we ask is this enterprise friendly, we will end up in different answers. It has enterprise friendly mechanism called AppServiceEnvironment to host applications in isolated environment ie an environment which is not open to public. Enterprise can host its internal services in it.

Though it says technically we can host any .Net application, it has good number of limits. For example if we have legacy application which uses any COM component, it cannot be used in AppService. This post is a journey towards such a limit

Puppeteer

It is a browser specifically Chrome automation framework in NodeJS. It helps to start headless browser instance and control it via JavaScript.  It needs a separate post to explain about Puppeteer. Ideally if we host the code in Azure NodeJS WebApp, it should work.

But fails due to unavailability of of some APIs in WebApp.

Details on WebAPI limits 

Below goes the error message
Error: spawn UNKNOWN
    at _errnoException (util.js:1022:11)
    at ChildProcess.spawn (internal/child_process.js:323:11)
    at Object.exports.spawn (child_process.js:502:9)
    at Function.launch (D:\home\site\wwwroot\node_modules\puppeteer\lib\Launcher.js:81:40)
    at Function.launch (D:\home\site\wwwroot\node_modules\puppeteer\lib\Puppeteer.js:25:21)
    at Server.<anonymous> (D:\home\site\wwwroot\server.js:14:39)
    at emitTwo (events.js:126:13)
    at Server.emit (events.js:214:7)
    at parserOnIncoming (_http_server.js:602:12)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:116:23) code: 'UNKNOWN', errno: 'UNKNOWN', syscall: 'spawn' }
started server.js

How to reach to a conclusion that Puppeteer not supported in Azure WebApp? Lets look at the below issue logged in their GitHub project


This will take us to the Azure Functions page which says Windows based Azure Functions don't support headless browsers? Really are there windows based functions and Linux based functions?

Unfortunately yes. The Below link explains the same.

This again takes us to the kudu page where the limit is documented.
https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#win32ksys-user32gdi32-restrictions

Moral of the story. Read the docs and understand what it really means.