Microservice architecture

Why

The idea of distributed, componentized applications goes back a long way. Most notoriously, it emerged in the form of the SOA trend. Now, it’s back — as micro services architecture. It is gaining momentum primarily due to the following factors:

1. Frustration related to not getting the desired output expected from architecture like monolith.
2. Availability of tools and technologies to develop and deploy microservices applications with ease.
3. Gaining momentum in adaptation of Infrastructure as a Service (IaaS), like AWS, Azure, or others, that have opened the door for easy DevOps operations.
4. Success stories of adaptation for microservices architecture by big technology product companies.

 

What is microservices architecture?

Microservice applications are composed of small, independently versioned, and scalable customer-focused services that communicate with each other over standard protocols with well-defined interfaces. Microservices are a more concrete and modern interpretation of service-oriented architectures used to build distributed software systems. Like in SOA, services in microservice architecture are processes that communicate with each other over the network in order to fulfil a goal.

 

Micro services architecture and SOA aren’t the same. In contrast to SOA, microservices gives an answer to the question of how big a service should be and how they should communicate with each other. In a microservices architecture, services should be small and the protocols should be lightweight. The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it much easier to change and add functions and qualities to the system anytime. It also allows the architecture of an individual service to emerge through continuous refactoring hence reduces the need for a big up-front design and allows for releasing the software early and continuously.

Good parts

• Each microservice is relatively small and easier for a developer to understand
• Organized around Business Capabilities
• Product mentality over project.
• Each service can be deployed independently
• Decentralize standards. Each independent component can use their exclusive standard
• Decentralized Data Management
• Easier to scale development.
• Improved fault isolation
• Eliminates any long-term commitment to a technology stack

Bad Parts

• Team communication overhead
• Formal documentation overhead
• Non uniform application
• Dev-Ops complexity
• Increased resource use
• Increase network communication
• Marshalling and unmarshalling
• Network security
• Testing
• Production monitoring
• High upfront cost

Who all are using them

• Netflix
• eBay
• Amazon

Conclusion

Whether or not microservice architecture becomes the preferred style of developers in future, it’s clearly a potent idea that offers serious benefits for designing and implementing enterprise applications.  Many developers and organizations, without ever using the name or even labeling their practice as SOA, have been using an approach toward leveraging APIs that could be classified as microservices.

Cloudy Days :How to host a WCF service in Azure cloud under a worker role.

using System;
using System.Collections.Generic;
using System.Threading;
using System.Linq;
using System.Text;
using Microsoft.ServiceHosting.ServiceRuntime;
using System.Configuration;
using System.ServiceModel;
using System.ServiceModel.Description;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Description;

namespace WCFHostingWorkerRole
{
    public class WorkerRole : RoleEntryPoint
    {
        private ServiceHost host1;
     
        public override void Start()
        {
            // This is a sample worker implementation. Replace with your logic.
            RoleManager.WriteToLog("Information", "Worker Process entry point called");
            //read configuration settings value
            string solutionName = RoleManager.GetConfigurationSetting("solutionName");
            string solutionPassword = RoleManager.GetConfigurationSetting("solutionPassword");
            string servicePath1 = RoleManager.GetConfigurationSetting("servicePath1");
            // create the endpoint address in the solution’s namespace            
            Uri address1 = ServiceBusEnvironment.CreateServiceUri(
                "sb", solutionName, servicePath1);           
            // create the credentials object for the endpoint
            TransportClientEndpointBehavior userNamePasswordServiceBusCredential = 
                new TransportClientEndpointBehavior();
            userNamePasswordServiceBusCredential.CredentialType = 
                TransportClientCredentialType.UserNamePassword;
            userNamePasswordServiceBusCredential.Credentials.UserName.UserName = solutionName;
            userNamePasswordServiceBusCredential.Credentials.UserName.Password = solutionPassword;
            // add the Service Bus credentials to all endpoints specified in configuration
            host1 = new ServiceHost(typeof(WCFDeltaLibrary.DeltaServices), address1);
            ContractDescription contractDescription = ContractDescription.GetContract(
                typeof(WCFDeltaLibrary.IDeltaServices), typeof(WCFDeltaLibrary.DeltaServices));
            ServiceEndpoint serviceEndPoint = new ServiceEndpoint(contractDescription);
            serviceEndPoint.Address = new EndpointAddress(address1);
            serviceEndPoint.Binding = new NetTcpRelayBinding();
            serviceEndPoint.Behaviors.Add(userNamePasswordServiceBusCredential);
            host1.Description.Endpoints.Add(serviceEndPoint);
            // open the service
            host1.Open();            
            while (true)
            {
                Thread.Sleep(10000);
                RoleManager.WriteToLog("Information", "Host is alive!");    
            }
        }

        public override void Stop()
        {
            // close the service
            host1.Close();           
            base.Stop();
        }
        public override RoleStatus GetHealthStatus()
        {
            // This is a sample worker implementation. Replace with your logic.
            return RoleStatus.Healthy;
        }
    }
}

Cloudy Days : How to view logs written by log manager in Azure

I will just walk through some simple steps to view your logs of an azure application  at development and after deployment in cloud. 

In the development machine you can view the logs by opening the Development fabric as shown in the figure below.

 

After You have deployed it in azure,azure will write the logs as an xml file.You can transfer the file to the azure storage account as a blob .

To do that follow the steps below

1. Go to azure portal and click configure under the deployment whose log you need.

 

 

2. Select your storage account in azure  where you need to move the log. Give a name

 

 

3.User Azure storage explorer to view the log ,which can be downloaded from http://azurestorageexplorer.codeplex.com/ (this is my personal preference)

 

Tadaa ..Your log is here