Heroku stopped their free tier. What's next?

Last year, there was a post about moving to Heroku from firebase as firebase mandated credit card even for the free tier. Also, that post explained the issues in giving credit cards for freemium services.

Good bye Firebase and welcome Heroku for free server side execution

As far as I am concerned, the main usage of this free server-side execution mechanism is to host a YouTube API proxy that will be giving data about my YouTube videos. 

Why API proxy? My Jamstack Hugo-based personal website (https://joymononline.in) is showing the list of recent youtube videos in my channels. As part of building the site, it makes a call to this API proxy where the API keys and throttling details are hidden.

The YouTube-proxy-API is coded in Node.JS so it can ideally be hosted anywhere supporting the Node.JS execution environment. Normally Node.JS is one of the first technology any hosting platform will support. 

Problem

Heroku announced that they are ending the freemium tier and it will be converted to eco plan with a scale of 0. Meaning there will be no web process running and it respond with HTTP 503 Service Unavailable. So what is next after Heroku for free server-side code execution? 

Alternatives

If we google 'Heroku alternative for free hosting' we get a handful of options. Netlify, Back4app, and Vercel to name a few. They all come with reasonable limits that are way higher than simple needs.

Render.com

Instead of trying the above list, I thought of trying something else called Render.com. The experience was very smooth. The code in the repo worked without any changes after hosting to render.com. Below is the link

https://youtube-proxy-api.onrender.com/api/channels/UC78wYrq_keVaDV8STReHRxg/videos

My Awesome freemium serverless cloud list will be updated later with the features of render to compare with other services.

I am not part of render.com and not affiliated with them in any way. It is an independent post about the experience with render.com

This is just a basic experience. This doesn't mean all scenarios will be easy as hosting a simple API.

Azure @ Enterprise - Serverless problems - Functions scales but Azure SQL and .Net Connection Pooling fails

Ideally this could have been a Twitter tweet.

Never make a intermediate component Serverless that auto scale

Serverless¹ is relatively new buzzword in the industry. We normally jump into serverless offerings as they are really attractive to manage and operate. The main feature that comes with Serverless is the auto scale. The Serverless compute that host out code is expected to scale out as the traffic increase.

Problem

If everything is that easy what is the problem? Let us consider the below architecture.

In case the architecture is not understandable, leave a comment. At first as a developer, we may not see any problem. But let us see this from the operations perspective.

• It runs most of the day time
• Intermittent failure starts in the evening
• In the night it works fine again

Root cause

Debugging this problem would not be a herculean task as far as there is proper logging.

The S3 Azure SQL tier has limits ² on how many connections. During the day there are only users the load they generate can be handled by S3 tier. Evening there is overlap. Demon apps starts and there are still users. Then it fails. Again in the night users are logged out and it serves all daemon apps.

The catch here is the Azure Functions will auto scale but the SQL cannot hence fails.

References

• ¹ https://en.wikipedia.org/wiki/Serverless_computing
• ² https://docs.microsoft.com/en-us/azure/azure-sql/database/resource-limits-dtu-single-databases?view=azuresql#standard-service-tier

Azure @ Enterprise - Serverless scale problem - Functions in App Service Environment connecting to Azure SQL

This post is about working with Azure Functions in App Service Environment hereafter ASE. Not sure it is qualified to call a classic problem but we all get into trouble when we use the serverless scale model. That is mainly due to the inability to scale by the dependencies of the Serverless compute tier.

To be more clear the Azure Functions will scale out but underlying dependencies such as Azure SQL will not scale with Functions and eventually lead to system failure.

Problem

Let us take a scenario. There is Azure Function that is invoked by the Azure storage queue. There will be one instance of Function running all the time. When the queue has more than 100 messages in the queued state, the Function will scale out to 4 instances to complete processing. Then scale down to 1. 

Each Azure Function instance can dequeue the maximum of 32 messages in a batch.32 is a hard limit.

When the scale-out happens the Azure SQL fails as it cannot accept more connections.

Observations

The SQL server sp_who2 command shows there are a lot of connections in the sleeping state from the Function instances.

The Azure SQL is in General Purpose Gen 5, 4 vCores tier. It can accept only 400 connections.

Root cause

.Net has a default connection pool size of 100. There are other applications also connecting to the same database apart from the Function. 4 Function instances wanted to establish 4x100=400 connections which are not possible with the Azure SQL tier as the other applications also making a similar number of connections. Hence it says cannot accept more connections.

Solution(s)

There can be multiple solutions

• Scale up the Azure SQL tier to General Purpose Gen 5, 8 vCores that can accept 800 concurrent connections.
• Throttle the .Net connection pool to 32 or 64. This number is based on the maximum number of messages dequeued by one Function instance. So max connections from all 4 pools will be maxed 128 or 256. There are some left for the other applications as well.
• The Serverless Azure SQL tier is an option. But please understand that the Serverless compute has a warmup delay after idle usage periods hence best suited for intermittent and unpredictable workloads that can afford this delay.

Happy Serverless

Awesome true freemium serverless clouds

What is the need for serverside code execution?

Nowadays JAMstack is getting popular. We can do almost all the application features in the browser application itself. JAMstack is a buzzword to represent browser applications that don't require a server to work. The application can be served from a CDN that stores application code in the form of static files. 

But there are many scenarios where we need to have some sort of interaction with a central location to access data or receive push notifications etc.

Serverless functions / FaaS

In such scenarios, Serverless functions can help us. Serverless functions or FaaS(Functions as a Service) is a cloud model where we can just host a function code without getting worried about servers and related configuration. Mostly pay per usage than a fixed monthly bill.

Freemium serverless functions

If we work for an enterprise or commercial application, we don't mainly care about free tiers. But if we are doing our personal projects we may research for any free service.

Fortunately, there are a lot of free options to run server-side code. Major cloud providers have free tiers but the problem is that we need to give them a credit card. The problem with the credit card is that we may get charged, in case of an attack such as DDoS is targeted to our function endpoint.

True freemium services

Firebase was my default choice as a true freemium serverless function provider. But recently they changed their model. They now require a credit card to avail of the freemium tier. 

This change caused the below GitHub project

https://github.com/joymon/awesome-freemium-serverless-clouds

The above link tries to aggregate all the true freemium service providers. Currently, it has only 3.

Have a look at the list and feel free to issue pull requests if there are other awesome freemium cloud providers.

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.

https://docs.microsoft.com/en-us/azure/azure-functions/durable-functions-versioning

https://docs.aws.amazon.com/lambda/latest/dg/versioning-intro.html

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/

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/

Azure @ Enterprise - Is Azure Functions Enterprise ready?

"It Doesn't Work That Way in Enterprise". This is a famous quote when we work in enterprise. Many things which does in a tick at startups never work that way in enterprise. Coming to Azure development, if we want to create a new Azure Function it might be just an entry in ARM template in startup and next deployment will have the Azure Function, but it might be 2 weeks process in Enterprise. Sometimes the Azure Function might have to be created manually based on tickets in Enterprise after multi level approvals and refer its name in ARM.

The focus of this post is 'Is Azure Function Enterprise ready?' Azure Functions is the flagship product from Microsoft to meet the demands of Serverless world.

Signing the assemblies

The basic thing in .Net is to sign our assemblies before shipping them. If we use third party libraries and those contain unsigned assemblies, we cannot sign our assemblies. 

Why we are discussing this basics with Functions? The current Azure Functions SDK which is coming via nuget package has references / dependencies which are not signed!!!

At the time of writing this post, Visual Studio 2017 (15.4.0) creates Azure Function projects which has references to unsigned dlls.

To be more precise, SDK has dependency to Microsoft.Azure.WebJobs.Extensions.Http which has the assembly with same name. If we open the assembly in JustDecompile, we can see the below.

Microsoft.Azure.WebJobs.Extensions.Http, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

It is reader choice to decide whether a SDK with unsigned assembly is Enterprise ready.

Beta dependencies of Azure Functions SDK

No need to explain in detail. The Function SDK has dependency Microsoft.Azure.WebJobs.Extensions.Http which is still in beta1 stage. Yes its the same which has unsigned assembly referred above. The latest Functions.SDK version available at the time of writing this post in nuget repo is 1.0.7 and it still has this beta reference. Refer the below link for dependencies. The SDK is in production but not the dependencies.

https://www.nuget.org/packages/Microsoft.NET.Sdk.Functions/1.0.7

Another thing Enterprise loves to put into production.

Pricing & vNet capability

If a service is internal ie called by other front end services or scheduled tasks etc..., enterprise never want to put it publicly. The solution in Azure Function to have internal service is to use the AppServiceEnvironment+AppServicePlan combination. What we loose there is the cost factor. ASE has fixed money in it and never pay per use.

Execution timeout of Functions

At the of writing this post the max timeout of a Function is 10 mins if it is in consumption plan ie the real pay per use model. But Enterprise may need to execute long running operations greater than 10 mins if there is queuing system or scheduled processes and those should be strictly internal. In order to achieve it they can never use pay per use model of Functions, instead use either ASE+Function or WebJobs. It would be considered as road block by enterprise users.

It seems Microsoft wanted to have an answer to Amazon Lambda in the Serverless world and someone hacked Azure WebJobs to become Azure Functions. But its really excellent idea for start ups to reduce time to market and reduce upfront investments.

Comparing Amazon v/s Azure Function for enterprise use is altogether separate topic.

Disclaimer

The Azure evolves at a fast pace and the facts might not be relevant in future.

Serverless JoymonOnline.in - Monitoring up and downtime of web sites

Side effects of Serverless

One of the side effect of Serverless is that is has so many moving parts and we need to monitor the health of all the services consumed by our application. In the case of JoymonOnline.in, there is no money involved but may be slight reputation loss when people sees the site down. How can this guy solve our problems in distributed systems if he can't make his site up all the time?

But that is not the case with real time web apps which brings revenue to the organization. Such scenarios demand the need for monitoring the health of third party services. Ideally we should design the system to switch to another alternative if possible. But at minimum we should know what is going wrong in the system.

JoymonOnline.in uses GitHub pages to host static content as it is HTML app developed using AngularJS framework. It is good to monitor the health of site as is.

Choosing monitoring service - Freemium

Freemium is a relatively new term in SaaS. When vendors sell Software as a Service, they often include a free tier to do all the basic things. For higher usage they start billing. There are many freemium services for web site/service monitoring too. One of such service is UptimeRobot. It checks the website in 5 min interval and informs us about downtime. It is very easy to setup. Only downside is it accepts only custom credentials. Not integrated with Google or Facebook logins.

https://uptimerobot.com

There are many other services like this. Of course this is best otherwise I would not have used it :) . A list is given below.

https://github.com/lexoyo/Monitoshi - Includes the source code and a free hosted instance.

https://visualping.io/pricing - Only 2 checks /day

https://www.labnol.org/internet/website-uptime-monitor/21060/ - Google doc script based.

Other lists

http://mashable.com/2010/04/09/free-uptime-monitoring/#FBROURLfQkqR
http://www.hongkiat.com/blog/monitor-website-up-downtime-30-free-web-services-and-tools/

Serverless JoymonOnline.in - Dealing with GitHub API and its limits

Introduction

This is continuation of my Serverless journey with my personal site www.Joymononline.in. As mentioned in previous posts, the main motive behind going Serverless is the cost. The principle is, 'Spend only for domain name. Nothing else'. Now the site is completely Serverless. But like anything else Serverless is not the perfect solution which can be applied everywhere.

One of the draw backs of Serverless is the lack of options to store developer keys at client side. In Serverless, we don't maintain any server but utilizes many third party services. Some services will be having limits on anonymous usage and some doesn't work at all without authentication. It can be overcome only by adding our own server side component(service) which acts as proxy between our client and third party service. Our server side component can have the developer key or API secret and utilize high quota from the third party service.

GitHub API limits

The open source projects from GitHub are listed in the site with some details. For showing that, GitHub API is consumed from the client side. But the GitHub API has limits. At the time of writing this post, if the request is not authenticated, it limits 60 requests per IP per hour. When authenticated, limit is 5000..Ideally JoymonOnline.in will never need that much requests for single user. But below are the situations where the API limits matter

• The site is opened from corporate machines where the external IP is same and simultaneously more than 60 people from a company opens.
• The user has opened another site which does heavy GitHub anonymous activity and after that opens JoymonOnline.in.

The first scenario may be rare as the my site at this point doesn't have that much reach. But the second is valid. So this issue is something to be addressed.

Overcome free GitHub API limits using proxy service

As mentioned above the way to overcome this is to place our own service in middle which has the developer key and let that service call GitHub API. The best way to create such a service is to use any  Function as a Service offering. There are many such as Azure Functions, Amazon Lambda, Google Functions, Webtasks etc... The selection criteria is based on cost ie it should be free (not even 1$ setup free) and ability to allow outbound calls to GitHub. Below code shows how the service can be written for Webtask. Why Webtask is selected will be coming as another post.

---

const http=require('https');
var express    = require('express');
var Webtask    = require('webtask-tools');
var bodyParser = require('body-parser');
var app = express();

app.use(bodyParser.json());

app.get('/', function (req, res) {
  res.json({ message: 'Welcome to my api!.Currently it supports api/joymon/<name of github repo>. Not open for all repos ' });
});
app.get('/joymon/:projectName', function (req, res) {
  console.log(req.params);
  var  callback = function(response) {
    var str = '';
    response.on('data', function (chunk) {
          str += chunk;
    });
    response.on('end', function () {
        res.json(JSON.parse(str));
        res.end(str);
    });
  };
  
  http.request(getOptions(req.params.projectName),callback)
    .on('error',function(err){
      console.log(err);
      res.json({ message: 'Soemthing went wrong when contacting GitHub API.' });
    })
    .end();
});
module.exports = Webtask.fromExpress(app);

function getOptions(projectName) {
  return {
        method:'GET',
        host:'api.github.com',
        path:'/repos/joymon/'+projectName,
        uri:'https://api.github.com/repos/joymon/'+projectName,
        json:true,
        headers: {'User-Agent': 'Custom Header Demo works'} //Add dev key via header

    };
}

---

If we have Webtask account, we can simply copy paste the above code and enjoy free service.

Client side changes

The GitHub API calls return headers which talks about quota and usage. The client side has to check that and call the proxy service accordingly. It is kind of retry which was never needed prior to Serverless.

http://jsfiddle.net/joygeorgek/arp6bmrj/5/

Overall Serverless brings benefits but at the same time, we have to do more such as retry and service orchestration. Also it brings so many points of failure and has to design for it. If one third party service is down we should continue giving the other features as normal.

Architecture of JoymonOnline - Serverless

This can be considered as continuation of 3 old posts.

• Architecture of JoymonOnline.in
• Welcome to Serverless
• Serverless JoymonOnline.in - Intermediate update

The first post, talks about the architecture of my personal site JoymonOnline.in. Other posts explains about new software architecture trend called Serverless and the conversion of my site towards Serverless architecture. 

This post explains the new architecture.

Architecture of Serverless JoymonOnline.in

Hosting

Hope the diagram is pretty much self explanatory. Its going to be pure client side single page application (SPA). In other words there is no page refresh when user goes to different view. 

The domain is going to be continued with Godaddy. But the hosting will be done inside Github pages, which is free. When we say Github hosting is free, it comes with limitations and quotas. But for my personal site those limits are not going to hit at least for some years :). It clearly tells that for a different person who is really famous the limits will come into play. So Github pages is not the silver bullet for hosting.

Flow

Once the client browser gets the static site(html,js & css) from Github, it becomes active by bootstrapping Angular components. It calls required services present in external systems for data. Most of these external systems are already mentioned in my previous post. After the data retrieval, the JavaScript updates the DOM with the help of AngularJS framework. The Angular JS version is 1.x used and there is a blog post explaining why 1.x is selected when Angular 2 is out.

Future candidates

• Azure Function - For Github & Blogger API due to anonymous quota limits.

Pros

• No cost to host web site. Just the domain registration. Most of the services are free.
• No need to license development tools. For  ASP.Net, Visual Studio community edition don't have much features.

Cons

• Multiple points of failure - Earlier, if JoymonOnline.in domain was accessible entire site works. But now all the domains of external systems should be accessible from the client machine which is not possible in all places.
• More dependencies - Has to monitor what changes in external systems and has to maintain accordingly.
• JavaScript restriction - Some browsers (inside some companies) might be still blocked to download JavaScript and execute.

Note - As of today (14Mar2017), the redirection for the site from Godaddy to Github pages to serve site has not done. But the site is up and running in Github pages joymon.github.io.

Serverless JoymonOnline.in - Intermediate update & experience

The Serverless is the new buzzword and it is getting really good attention. It is nothing but an architectural style where developers don't need to worry about servers for deployment, scaling etc... Just write and push the code. It will scale automatically.

In the previous article about Serveless, I had mentioned I am in the process of converting my personal site to Serverless. The decision was purely financial. Why should I give money to GoDaddy for hosting some pages which can be served by GitHub pages for free?

This is just an intermediate update about that effort.

Steps

Below are the steps taken during this effort. It may vary from project to project based on complexity. JoymonOnline.in is just a profile site which don't use any custom modules or handlers.

1. Avoid server side data rendering
1. Replace .Net third parties with equivalent JavaScript API
2. Convert each .aspx page to contain its own Angular application.
3. Avoid ASP.Net specific skin files and use pure CSS
2. Client side integration
1. Replace ASP.Net master page with Angular routing.
2. Bundling, Minification, CI & CD
3. Backward compatibility
1. Links
2. SEO

Please note that these steps are relevant if the decision is 

• Not to start a fresh app
• To ensure that the code base is ready to delivery at any point in time.

If business can keep quite during the migration or the development can be done is separate branch ad later merge, these steps are not required. Just start a new app.

Avoid server side HTML rendering

The current www.JoymonOnline.in site uses ASP.Net web forms technology. In other words it uses server side HTML generation and sends it to the browser. There is no rule that Serverless should not use server side rendering. It can use, provided the server side rendering can scale automatically without doing any extra task. For example a WebAPI service end point can return HTML and it can be rendered at browser with the help of JavaScript. That introduce some kind of client side HTML manipulation. Once we take that decision, there is not much differences between rendering full contents at client side v/s rendering some contents at server and inject it to client side views. So in short Serverless goes hand in hand with client side web apps which we generally call SPA (Single Page application). It can't be done in one step. So sub tasks are as follows.

Replace .Net third party with JS API

If we want to replace the third party .Net API with JS equivalent there are 2 options

1. Use equivalent JS library
1. Has to make sure the critical API keys are not exposed. Can do client site authentication or be happy with free quota.
2. Write a FaaS which uses same .Net API and let it return required data to client.
1. We have to make sure it is secured and key present only at service and service can only be called from our app.

Coming back to JoymonOnline.in, it uses some third party APIs at server side to get data and render  via ASP.Net. GitHub API, Blogger API are the main third parties. So these calls needs to be done from client machine. For GitHub, it was easy as there is straight JS library. But for Blogger it was little difficult as the Google feed API is discontinued. Finally it worked with blogspot feed url.

But for GitHub, there is a limitation due to the quota for unauthenticated API calls. Since the developer key cannot be exposed to client, it allows only 60 requests / hour / IP address. Since JoymonOnline.in is expecting more than 60 calls from single API it is ok to go with quota. 

Convert each .aspx page to contain its own Angular application

Next step is to convert page by page to Angular. This is to make sure that the application is always in functional condition than like a demolished house before renovation. Convert individual pages to its own angular app and render that app inside the ASPX pages. Let that page be just an angular app host. Noting else. 

In this step we have to identify equivalent third party ASP.Net UI controls, if applicable. For example how to replace Telerik web forms controls with KendoUI.

In case the plan is to first get to ng1 and later to ng2, I would strongly recommend to go with components rather than directives. TypeScript is becoming defacto standard for angular. Use that to avoid debugging time. After this step, we will have ASP.Net application but the functionality working from browser via angular.

Avoid ASP.Net specific skin files and use pure CSS

Next thing to tackle are the styles. If the application is using skin files, we have to get equivalent CSS files. Sometimes we may need to do this along with the previous step. Depends on nature of third parties and our code.

Client side integration

The next big step is to integrate things at client side.

Replace ASP.Net master page with Angular routing.

The main pending thing is to have angular master page and routing. We already have separate components in different apps. Just create new app in index.html and have the routing to load proper components. This steps sound simple but it has many things to do.

Bundling, minification, CI, CD etc...

Now its the time to optimize the site and do integration to build pipeline. Till this point, the expectation is that we are able to use existing build system. Recommended is Webpack for client side activities such as compilation and bundling. CD is always confusing with Continuous Delivery and Continuous Deployment. At least make sure it is Continuous Delivery.

Current, JoymonOnline.in using AppVeyor for CI & CD. Though AppVeyor is mainly intended for Windows development, it supports NodeJS as well. So decided to continue in AppVeyor. At this point the build output will be pushed to \docs folder as staging. GitHub pages recently started supporting serving web pages from \docs folder instead of gh-pages branch.

It is not fun to develop JS based client side app using Visual Studio solution file. After this step we don't need .sln file to work with. Node rules the client side web development world. At some point we have to introduce Node. So why not from the start if it is possible to live with only Node? When it is said 'start', it means the starting of the migrated application. If anyone feels they can live with .sln file without Node, let them continue. But better don't use mix. Comparing Node with .sln is not the right comparison. But the intention is to use Node and its ecosystem such as NPM & package,json etc... 

Backward compatibility

These may be optional depends on scenarios.

Links

This will make sure that the bookmarks saved by users are still valid. The old ASP.Net application could have modified to redirect the .aspx pages to new URLs. But for JoymonOnline.in, this is not done.

SEO

The SEO efforts needs to be put if the application is public facing.

These steps itself needs explanations which will be having contents enough for separate post. At this point, the entire application has converted and available at joymon.github.io . The main pending thing is to change settings in GoDaddy to point JoymonOnline.in records to joymon.github.io.

Why I choose Angular 1.x for www.JoymonOnline.in while Angular2 is out

What is the present tech landscape?

If we look at present web development technologies, we can see everything is revolving around client side HTML generation. The interesting thing at client side web development is that, there are new tools and frameworks getting released every week. It is very difficult to select one and get something out using that. By the time we complete analysis on one tool or framework, the next one will be out by saying its better than the existing. If we keep analyzing, we never will be able to do something useful.

Recently, I decided to convert my personal web site to pure client side solely to avoid hosting cost. It currently is .aspx based server side html generation model. The server side code help me to connect easily with third parties such as Github, Blogger etc...I don't need to worry about whether the viewers network blocks GitHub or Blogger APIs. If I am converting to client side I had to write some JavaScript to do that third party integrations. Hence I have to analyze the client side technology stack. Important thing for me is to convert the app to pure client side app before March 2017 else I have to renew the hosting space again. So its is highly time bound

In short, I selected Angular JS 1.x over other technologies even by avoiding Angular 2. This post talks about my journey towards Angular JS 1.x to do this time bound task over Angular 2.

There is no standard tooling for ng2

We can easily compare the scenario with the US restaurants v/s Indian restaurants.

In India, if we got o middle or lower level restaurants and order Masala Dosa, they will give us a standard Masala Dosa. The standard changes from state to state and district to district. Very less options to customize. But if we are in American restaurant, they will ask so many questions, if we order a sandwich. What type of cheese, what ingredients, type of bread etc...

In Angular 1, things were pretty much like restaurants in India. There are standard tools. Only some confusion comes in the language. Whether to go with JavaScript, TypeScript or CoffeeScript.

But in Angular 2, there are many tools and we have to pick up the combination what works for us. What framework for module loading, how and when to compile TypeScript to JS, how to do packaging.  New tools are popping up frequently too. Though there is official recommended tool chain, I don't think it is working out for many developers. May be they are not productive or are complex which needs more technical knowledge. Else people will never spend time to invent more and more tools.

Though the ng2 framework is kind of mature the tools are not.

This may be controversial statement. There will be many disagreements as some tools works for some and all can find some combinations.

Many tools are in beta

The main tool came along with ng2 is the command line tool called  Angular cli. At the time of writing this post, it is still in beta. They recently switched from SystemJS to WebPack. 

Some tools doesn't mean for Windows

Suppose we take the risk of using a beta tool for doing development, there are still issues. Some are more tailored to OS other than Windows. Though we can mitigate the issues, it eats our time.

Compiling TypeScript in browser is for demos till browsers understand TypeScript

Now a days most of us agree that the compilation of TypeScript needs to be done along with build process. Though there are options available to compile TypeScript in browser, it will reduce the start time of our application. The other group is telling that, some browsers are expected to support TypeScript directly in future so the compilation can be done by detecting the browser.

This is same, if we select ES6 as well. Some says we should compile down to ES5 always the other side argues that it should be done at Browser by detecting the feature support.

Its all good if we are developing a demo to get a project or samples. But for something to be done in a time based manner, we cannot be trapped in these arguments.

Why not code Angular2 in ECMA 5 JS?

Come on...Though there are many good tutorials available which explains writing Angular 2 application using ES 5, I never want to do. There are many reasons. One big reason is going forward, if we struck in an issue the sample snippets or solutions provided will never be in ES5. We have to find out how to convert the ES6 or TS code into ES5.

But we should definitely try writing the Angular 2 code in ES5 for understanding purpose. Else if something goes wrong in our compiled ES5 code, we may not be able to find out.

Why not build a brand new site and switch one morning

This is a famous question we all might have faced during any migration effort. The developers who never tried rewriting a software under proper timelines, will always advocate this strategy. But others never agree on complete rewrite. When we look at any software which is running for long, we can see so many pain points of previous developers and hacks, anti patterns etc...If we just start rewriting,  we will also have to go to the same pain points. So why should we take unwanted risk? Lets always divide and conquer part by part.

In my personal web site scenario, I was the only developer and I am the one who is going to rewrite also. But I had taken so many things from here and there during initial development and unfortunately, I didn't document anywhere even in this blog. Since I use my brain mainly for generating ideas, I don't remember all the pain points now. Hence there is no need to take risk.

Again why should we take same old risks as there will be new risks during the conversion to client side.  By this time I already got an issue related to Angular date formatting in Windows Phone 7. Please don't ask apart from me who else using Window Phone.

The continuous delivery system

I currently use free service from AppVeyor to run continuous delivery of my web site. Since its a Visual Studio solution, AppVeyor detect it, compile the same, run tests, package and deploy to the server. To my best understanding ng2 heavily depends on NPN though there is a nuget package for ng2. AppVeyor can be configured to use NPN, but it is again time consuming.

When is the best time for ng2

None of the tools and technologies are going to be there for ever. The technologies are suitable to the current landscape. There are new cool technologies coming out. Below are some

• ReactJS (This is already out. Though it is not a full fledged framework like Angular, it is a choice)
• WebComponents
• WebAssembly (we may be developing browser apps using C#. Remember the old Silverlight days)

The driving factor in this conversion is the cost to host ASP.Net site. After that based on the situation, there may be pressing situation to convert to any one of the above technologies. But right now, it is impossible to predict.

---

These are my own views about selection of AngularJS 1.x for a personal/portfolio site. These are not  applicable to all the scenarios. 

Welcome to Serverless

After Microservices, the next revolution in Software Architecture is Serverless. There are already many great blog posts on this subject and some I have indexed at the end. This is my own views on Serverless.

Some history 

As we know servers are just another computers. Similar to desktops they have Processor, RAM etc...fixed on mother board and motherboard needs power. Probably they might not be having dedicated keyboard or monitor instead they can be remotely controlled. These physical server machines normally will have high hardware configuration which is not needed for normal workloads. So there resources are shared by hosting multiple small machines inside it and we call them as virtual machines. Another reason for VMs is that we can easily manage the VMs by software. For example we can delete a windows VM and create Linux VM completely via virtual machine managing software. Also we can easily adjust virtual machine's RAM, Hard disk etc.... 

In a traditional in-house data center, we as operations engineering/infra team have to make sure there are enough physical servers so that we can respond to the dynamic needs of VMs from different apps. At any given time, most of the machines will be under utilized considering their capacity. From software developer perspective, they have to make sure these machines are having proper software installed and had to scale up / down / out based on the usage. The old gen cloud environment ie IaaS solves this issue of provisioning machines easily. At least the infrastructure operations team is happy.

The application software side was not happy with IaaS because their duties were not reduced. That's why cloud is evolved to more abstracted levels such as PaaS, SaaS etc...In every higher level, more abstraction is getting added and developer is going away from the hardware and concentrate on the software aspect of the system.

Enter PaaS

In PaaS, developers don't need need to worry about the platform and scaling is less painful than IaaS. Using a slider or command they are able to control scaling. Some cloud providers provides auto scaling at this level but developers had to write some code to determine when to scale. This really solves, if the software is going to be deployed as a package/bundle which does related task. eg: a website or APIs exposed via web.

In PaaS, since the unit of deployment is package, the scaling applies to all the tasks in it, regardless of the individual task usage. Eg: We have 10 APIs in a WebAPI deployment and only 5 are getting high traffic. But when we scale, entire WebAPI deployment get scaled.

Enter FaaS (Function as a Service)

We saw the scaling issue in PaaS. One way to individually scale each task is to split the deployment package to task level so that each deployment package has only one job/task. This is somewhat  Microservices tried to achieve. Split the app as much as possible.

But that still needs monitoring. Someone has to monitor and adjust scaling based on usage. Lazy developers wants to get out that as well and there comes FaaS. Here each function becomes a deployment unit. When it came to FaaS, the cloud providers were able to provide real auto scaling. Developer don't need to monitor anything. The provider does it.

What is Serverless

If we examine the PaaS, the cloud providers kind of started managing server. We just had to give a deployment package the rest will be done by provider. But there was monitoring overhead. When it came to FaaS the the cloud providers started taking entire ownership of servers. But those were not only the factors for the rise of Serverless.

Free high performance server side execution

Along with taking the hardware away from developers, many cloud providers started giving free tiers. Since its per function, the cost of starting a cloud based business became very less. At this point nearly 0. So obviously startups selected this way so that they can try out their ideas in this model without much investment. They can market things very fast and even if it fails, they are able to manage the financial loss. Earlier, there were very less options for getting free industry grade server side code execution.

Free industry grade HTML hosting 

Another boost is the availability of free HTML web hosting providers. It was there from the beginning but they were not ready to host high traffic sites. But that is not the case with git pages, amazon S3 hosting. Now with $0 hosting cost, anyone can start online business. Only thing they need to know is how to do basic HTML+JS coding and integration skills.  Integration skill are nothing but calling the above mentioned free server side APIs via XmlHttpRequest or simply AJAX.

Fremium SaaS

One more benefit came in the situation is the availability of many freemium services to do cross cutting concerns or shared capabilities. If we want to provide login integration with Google, Facebook etc..., its's now matter of some hours.

Success of standardized web & Availability of mobile & high speed internet

These are some additional positive things happened which boost the evolution of Serverless. If different browsers were behaving differently, jQuery & AngularJS were not invented, internet was giving in dial-up the word Serverless might not have been heard.

Overall, the startup community found it cost effective and since they are the drivers of innovation and conferences Serverless became the next Jargon. Obviously with the support of the real giants or the cloud providers. Very soon enterprises will also follow the same route.

Are there really no servers?

There are servers but entirely managed by the cloud provider or the SaaS provider. Without server ie some higher end computers or generally hardware, we cannot run our web based softwares except peer to peer such as torrents. The term just makes confusion. 

I am using FaaS. Am I in Serverless?

We have to understand first that the web applications has 2 ends. One is the front end which runs in browser, served from a web server. The other is the back-end, where the data lives and computation happens. Back-end we can again divide to computation layer(business layer) and data layer. Using FaaS make sure that our computation is Serverless. But what about data layer and front end. If the front end is served from in-house data center or from IaaS virtual machine, we cannot say the application is  Serverless. This is applicable to databases or files in data layer too.

So if we are not at all worrying about any server, we can say our application is Serverless. 

Does Serverless means free?

Serverless is an architecture pattern and doesn't mean it is free. But if we are choosing this architecture, we can have application up and running in zero hosting fees. Development cost is always there. Mostly everyone starts in free tier and upgrade to paid when they get success. That move doesn't usually involve any code change.

Does Serverless require strong upfront arch design?

Serverless provides great flexibility to development similar to Microservices. We can choose multiple languages which suit to the service / function. Easily get rid of technical debt by rewriting hot functions. Architecture can be easily changed as its only at the integration level.

But that demands a good architecture vision on integration. Else the functions will not work together to produce desired behavior.

Will there be function hell?

Yes, if the management & monitoring of the functions not done properly. If we let every Tim and Harry to start writing functions without a monitoring mechanism, we will soon end up in so many functions in the production environment and nobody knows why they exist.

Does the Serverless arch require CI,CD pipeline?

Though architecturally doesn't require, its advvised to setup proper CI, CD pipeline to take advantage of this model. This is applicable in Microservices too. Else it will take unnecessary integration efforts.   

Should I switch to Serverless tomorrow?

When the cloud is announced many industries were not ready to accept and the concern was security. But now we can see the direction is changing. Even banks are trying to use cloud as much as they can. There is no question that Serverless will be the future similar to how Microservices are doing now. But as always before we convert our existing app or start next app using Serverless, we have to compare the pros and cons. 

The below comparison assumes that Serverless uses FaaS along with SaaS. So some factors may seem suitable to FaaS or SaaS.

Pros

1. Single responsibility at function level - This is something we were trying to achieve from the beginning of software but at the mercy of developers which is very difficult to get. But with Serverless, this is enforced by architecture. 
2. Cost - Theoretically it should be less as we are truly paying for what we use. But has to wait for more real time high volume usage reports.   
3. Scale out coding - Coding can be scaled out efficiently and done even in browser. But this is good, if there is proper high level integration plan.
4. Ease of code management -  Also we can easily get rid of technical debt by rewriting functions.
5. More selection of languages - We can select different languages for different functions similar to Microservices. But this is double edged sword.
6. Easy switching of provider - Since the deployment is at function level we can switch provider gradually function by function.  

Cons

1. Many points of failure - Since our app may depend on many SaaS, if one of them down our entire app may get down. Else we have to use fallback mechanisms.
2. Not all SaaS available equally in the entire world - If we are using Facebook as the only login provider, people from countries where Facebook is banned cannot use our software. Also any country or region may block anything. So need to monitor the world. 
3. Function hell
4. Performance - The end user don't need to worry that the app is Serverless and the performance hit is due to X SaaS or Y cloud provider. To them the site /app is single unit and ensuring performance is the developer's duty.
5. Integration complexity - The total business complexity of app cannot be changed but can be moved. In Serverless tt just moved from component level  to higher integration level.
6. Performance of chained calls - If the business requires complex processing chain, it may affect performance. Better those should be queued.
7. Performance of service instance activation - Upon a trigger the cloud runtime is expected to select one from existing or start a new runtime environment for the function before execution. The time to setup that environment affects the performance. This depend on the provider specific FaaS runtime implementation.  
8. Less control - If we have a unavoidable scenario of long running service, the provider may kick out our service instance due to timeouts. Not an arch level disadvantage. Its provider dependent.
9. Lack of tooling - This is a temporary disadvantage. Soon more tools, IDEs and offline testing solutions will evolve.
10. Developer forgets hardware - This can be seens advantage as well as disadvantage. Discussed more below.

Serverless makes developers moving away from hardware

This is a debatable. But whatever debate we do a good chunk of developers are getting away from hardware. But is this started with Serverless?

Never. The move has started when the assembly language is invented. Instead of 1's ans 0's people then started using Mov A,B or PUSH B etc...The compilers took it further. Later the managed platforms came with virtual machines. Those were all driving the developers from bare metal machine.

The great developer divide 

But whatever happens, there is a hardware which understand 0's and 1's. Who control the machine. Obvisouly the compiler writers & runtimes coders. They are still with the machine and require high skills than the business application developers. We can now tie the cloud runtime developers into the same group. Those skills are not replaceble with AI. But the business developer will soon or later taken by AI. Another group of developers who will join with the system and cloud makers are the AI algorithm authors. There are already sites like Algorithmia who facilitate Algorithms as a Service.

This is more like the natural evolution. It take considerable amount of time to see 2 species of developers. Its again it's own topic to be discussed in separate post and not sure the term 'The great developer divide' suits to the phonomenon.

Whether the author use Serverless?

I always believe in solving my problems first before I solve other's with my code. Yes I am taking  2 of my personal projects to Serverless. My personal website http://www.joymononline.in & Karel simulator. My main motivating factor is the hosting cost than the eager to try out new Architecture. More updates will be shared later via this blog.

References

• http://martinfowler.com/articles/serverless.html
• https://read.acloud.guru/serverless-the-future-of-software-architecture-d4473ffed864
• http://highscalability.com/blog/2015/12/7/the-serverless-start-up-down-with-servers.html