Tuesday, November 29, 2016

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

Tuesday, November 22, 2016

Pipelining events in C# .Net

The concept of Events is a good technique in .Net for establishing publisher-subscriber mechanism. When we work on .Net projects there would be situations where we have to raise an event when some of our dependency raise an event.

For example, our class A holds object of class B. A receive event BE1 from class B and fires AE1. A Simple event relay mechanism.

How that can be done inside class A?

Receive event and fires next event

class A
{
    B bObject=new B();
    public A()
    {
        InitializeB();
    }
 
    private void InitializeB()
    {
        bObject.BE1 += BObject_BE1;
    }
 
    private void BObject_BE1(object sender, EventArgs e)
    {
        this.OnAE1(e);
    }
 
    public event EventHandler AE1;
    protected virtual void OnAE1(EventArgs args)
    {
        if (AE1 != null)
        {
            AE1(this, args);
        }
    }
}
Below is the code for class B. It uses a simple timer to fire events.
class B
 {
     public event EventHandler BE1;
     protected virtual void OnBE1(EventArgs args)
     {
         if (BE1 != null)
         {
             BE1(this, args);
         }
     }
 
     #region Event raising code
 
     public B()
     {
         Timer t = new Timer(2000);
         t.Elapsed += (sender, args) => this.OnBE1(EventArgs.Empty);
         t.Start();
     }
 
     #endregion
 }

Passing the delegate

Lets see another technique for this event forwarding.
class A
{
    B bObject = new B();
   
    public event EventHandler AE1
    {
        add
        {
            this.bObject.BE1 += value;
        }
        remove
        {
            this.bObject.BE1 -= value;
        }
 
    }
}
Hope this property kind of syntax is familiar to all the .Net devs though it not used daily.
What are the differences?

Receive and fire

Passing delegate

The delegate of events can be different Delegates should be same
Even if the inner object is recreated there is no difference If the inner object is recreated event will not propagate
The sender of event will be originator classThe sender will be always the inner class
The intermediate class has to deal with dynamic event subscription in case there are multiple threadsIntermediate class don't need need to worry much about multiple threads
Happy coding.

Tuesday, November 15, 2016

How to make .Net process Singleton

Its a common scenario we encounter in traditional windows application development that we need to limit our process's instances to one. Especially if its a giant LOB WPF or WinForms which consumes good amount of memory, we will be forced to limit the instances of application to one. This post is explaining how that can be done.

Please note this is a solved problem. Many of us are doing it.

Using process name  

This is the most common method we can see to limit the process instance. Every time the process will check whether there is any other processes in the machine running with same name. Code snippet below
class ProcessHelper
{
    public void PrintIfThereIsAnotherProcessInstanceRunning()
    {
        IProcessInstanceDetection processDetection = new NameBasedDetection();
 
        bool areThereAnotherInstances = processDetection.IsAnotherInstanceRunning();
 
        Console.WriteLine($"Current process name {Process.GetCurrentProcess().ProcessName}.");
        Console.WriteLine($"Are there another instances : {areThereAnotherInstances}");
        //Handle the result.May be terminate second instance. 
    }
}
interface IProcessInstanceDetection
{
    bool IsAnotherInstanceRunning();
}
class NameBasedDetection : IProcessInstanceDetection
{
    public bool IsAnotherInstanceRunning()
    {
        return Process.GetProcessesByName(Process.GetCurrentProcess().ProcessName)
                      .Count() > 1;
    }
}
class MutexBasedDetection : IProcessInstanceDetection
{
    private const string MutexName = "SomeGUID";
 
    public bool IsAnotherInstanceRunning()
    {
        bool created;
        Mutex mutex = new Mutex(true, MutexName, out created);
        return created == false;
    }
}
The interface is used for easily switching the logic. Here the name of the current process is used to get processes with same name and if there are more than one, current process may terminate. The code to terminate is not present in this sample.

First time when the process runs the count will be 1 and the process can continue. Next time the count will be 2 and its > 1 so the second process needs to be terminated itself. It's not a managed termination. Process has to exit itself. 

Pros

Simple mechanism to implement.

Cons

If someone rename the exe file name, the process name will change and second instance will run. Also if some other application from different vendor is also using the same exe name, our application will not run. Especially if our exe name is generic such a monitor.exe or starter.exe etc...  

Using Mutex

Here we use Mutex which is visible to all processes. The implementation class for the Mutex based duplicate process instance detection is below.
class MutexBasedDetection : IProcessInstanceDetection
{
    private const string MutexName = "SomeGUID";
 
    public bool IsAnotherInstanceRunning()
    {
        bool created;
        Mutex mutex = new Mutex(true, MutexName, out created);
        return created == false;
    }
}
Hope we all know what is Mutex means. If not please refresh. Here when the code is executed for first time, the Mutex will be created and it detect as first instance. Next time when the same process's different instance is started, the Mutex will not get created and the program can terminate itself.

Since the first code snippet is showing the usage, here only the new class is included.

One problem we can see here. If we use "SomeGUID" as Mutex name, there are chances for our logic to fail, if any other process create a Mutex with same name. So better generate a GUID and include that in our source code. Practically the same GUID will not be generated second time.

Pros

  • Even the exe is renamed, it will detect second process instance.

Cons

  • The Mutex name is the key part here. If its .Net, anyone can decompile the app and find the value if they really want to make trouble.
  • If same process try to check whether there are only single instance, the result may vary. So need to tweak the sample code above to handle.Please note its not because of this approach, its because of the logic in sample code.
We can think of many ways to make our process single instance. But these are the common ways.

Tuesday, November 8, 2016

TypeScript : Writing first typedefinition file for our JavaScript library

TypeScript doesn't have its own runtime. But it makes the JavaScript coding much easier and maintainable. TypeScript and JavaScript goes hand in hand as every valid JavaScript is valid TypeScript. But what if we already have a JavaScript library and we don't have budget to convert that to TypeScript. Can TypeScript call JavaScript functions inside the library?

A JavaScript Library

Wiki says "JavaScript library is a library of pre-written JavaScript which allows for easier development of JavaScript-based applications..". Mainly JavaScript libraries expose their functionalities via objects or functions. Below is a JavaScript library to do some math functions.

//Code math opeations
var MathLib = {
    Add: function (n1, n2) { return n1 + n2; },
    Subtract: function (n1, n2) { return n1 - n2; }
}

This can be easily invoked from anywhere in JavaScript as its a global variable.
function btnclick() {
    alert(MathLib.Add(2,3));
}

Entering the TypeScript world

Now lets see how the above library can be used from TypeScript. If we simply copy paste the JavaScript function to call the library, it won't compile. That is because TypeScript don't know what is the type of MathLib object and don't know whether there is a function called Add() is there in that object.

So what to do? If we want to call any JavaScript library we need to make sure its available in TypeScript. That can be done by writing type definitions for JavaScript library.

declare var MathLib: IMathLib;
interface IMathLib{
    Add(n1: number, n2: number);
    Subtract(n1: number, n2: number);
}

Include the above declarations into TypeScript file then we can see it is compiling and producing same JavaScript code.

What magic happened here? We told TypeScript compiler that there is an variable called MathLib and its type is IMathLib. That type has 2 methods and the signature of those methods. We can tell that the arguments are 2 numbers. Now TypeScript passes the compilation assuming that during runtime there would be an valid object in the variable MathLib with 2 functions with proper names.

The interface name can be anything but the function names should be exactly same. the parameter type can be any valid type in TypeScript including the 'any' type.

Virtual TypeSystem of TypeScript

The type system in TypeScript exists only during compilation. During runtime nobody is enforcing types. This is because the runtime is JavaScript and that is not a hard typed system.

What is <filename>.d.ts

d.ts extension is a convention in TypeScript used to group all the TypeDefinitions. So that our application code will never be confused with TypeDefinition files.

Just move the declare var... line to a file named defs.d.ts and include to the project. It will compile. If there are any compilation error make sure your .ts file which consumes the library has a referene to the type definition. Sample code below

/// <reference path="defs.d.ts" />
function btnclick() {
    alert(MathLib.Add(2, 3));
}

Writing TypeDefinitions for third party JavaScript library

The above clearly shows in the TypeScript world the consumer of the library can simply create the type definitions for any JavaScript library. When we want to write type definitions for large libraries better make sure we are creating proper modules so that there is a clear separation. Also use exports properly.  

The type definitions for all most all famous libraries are already available in internet. One of the repository for type definitions is DefinitelyTyped

References

http://peter.grman.at/how-to-write-typescript-definition-files/
http://www.codeproject.com/Articles/528295/ModularizationplusinplusTypeScript