With more and more applications moving to the cloud, it is important for developers and architects to start thinking in terms of applications which are ready for cloud deployment. Spring cloud in an umbrella which consists of a set of spring projects that can help us create applications which are cloud ready. The advantage of using a spring cloud is that you get a solution to most of the challenges you face when you deploy on the cloud at one place.

Let’s look at some of the core tools provided by spring cloud.

Spring Config: An important challenge distributed applications poses is how to manage your configurations. Each application and service need to manage some configuration properties. Spring config server provides a centralized way to manage configurations. It can read configuration from multiple sources, by default it would expect the configuration to be available at Git, but this can be modified. The most important factor of about using spring configuration server is that you can refresh properties or configuration in services without the need for redeployment or restarting the services.

Discovery service- Eureka: Spring cloud borrows a lot of services from Netflix open sourced projects. Eureka is one such service from Netflix, which provides a discovery mechanism for services deployed, Spring provides seamless integration to Eureka. With a design supporting deployment and autoscaling fo microservices, this becomes important the services can be deployed and removed on the fly without manual interaction. A challenge in this approach is how will the calling services know about the location or URL for the services to be called. A discovery service mechanism provided by Eureka comes to help. Any new service getting added to the system will register itself with Eureka server. A service that needs to access this remote service will communicate with the Eureka server and ask for the service location. Eureka server returns the location of the service, which is then accessed by the client service.

Fault Tolerance with Hytrix: Another important factor one needs to be worried about is how failure is managed in an application. In a distributed system, where multiple services are calling each other, will the failure in a service bring down the whole system? Or is there a way we can contain the failure to a single service. Spring integrates with hystrix, which again is a project by Netflix, that provides us mechanism like a circuit breaker to manage failures in an application. For example, if a remote service is down or not responding, Hystrix helps us configure an alternate service or method which can take over. Also, we can add settings that after N number of failures, client service will stop calling remote service (the circuit is open), and set a timer when next retry happens (if the service has healed itself, operations continue as usual).

Routing with Zuul: With multiple services being part of the system, it becomes difficult for client service to keep a track of all the remote services. A routing gateway in such an environment is like a front gate, behind which all the services are available. A client system need not be aware of details of deployment of each service, and it will just request routing server to get the required information, which in turn will communicate with remote service and returns a response. The advantage of this approach is we can implement security, logging, auditing of incoming requests in a centralized manner and each individual service need not worry about these factors.

Load Balancing with Ribbon: Load balancing is an important feature in order to manage autoscaling of the services. If there are 10 instances of a service, we want to make sure each of the instances manages almost equal load to take advantage of scale. Load balancing can be implemented at the server level for which various cloud service provider already give us a certain option. But there can be cases when you want to implement Load balancing at the client side. For this, Spring integrates with Ribbon project from Netflix and provide us seamless load balancing with the help of annotations like @LoadBalance and @RibbonClient.

Additional Spring Cloud projects: As already mentioned spring cloud is an umbrella which contains a number of projects that help us make our application cloud ready. The number of projects under this umbrella keeps on increasing with an increase in the popularity of cloud-based deployment and distributed applications. For a detailed view of all the projects under spring cloud, one can visit and explore projects under https://spring.io/projects/spring-cloud

When one goes for a Cloud based solution with solution provider like Amazon AWS, there are 2 things which are important. One, you need to have a clarity on what you are trying to achieve, and second is understanding of the services being provided by the provider.

Both the aspects are equally important. AWS provides plethora of services which can amuse at the same time confuse one. You might be tempted to use services which might not be required for your project and unnecessarily adds to the cost. At the same time if services not used with proper understanding, can backfire in terms of output and cost. For example, in one of my projects, incorrect implementation of autoscaling ended up running unused servers adding to cost instead of saving it.

Additionally, one need to be aware of all the capabilities of the service provider, for example, what all database and backup services we can use, can we use caching services, monitoring services provided by the service provider. Otherwise you will end up putting in unnecessary effort in rebuilding the wheel.

Here is a good starting point for AWS usage –

When you are setting up an environment on AWS cloud, you need to go through many steps, like creation of IAM roles, Security groups, Databases, EC2 instances, load balancers etc. Often one resource is dependent on other and hence you have to create components one by one which can be time consuming. With Cloudformation scripts one can easily get the deployment steps automated. And most importantly, the script is reusable any number of times. So if I want to replicate a stage setup on production or another setup in another region, it is easily possible.

One can create template in JSON or YML formats. The template is submitted to cloud formation which executes the template and create the stack which is actual environment with all the mentioned components.

Another important thing is that you can not only create infrastructure, but also do required settings. For example, I needed to get setup for application done on EC2, which I was easily able to do with UserData section.

Here is an example

Resources: 
    AppNode1: 
        Type: AWS::EC2::Instance
        Properties:
            InstanceType: XXXXX # type here
            ImageId: ami-XXXX # any ami here
            KeyName: XXXX # name of the key if already exising or create a new one
            IamInstanceProfile: !Ref InstanceProfile
            NetworkInterfaces:
            - AssociatePublicIpAddress: true
              DeleteOnTermination: true
              Description: ENI for bastion host
              DeviceIndex: '0'
              SubnetId: subnet-XXXXX
              GroupSet:
              - !Ref AppNodeSG
            UserData:  
              "Fn::Base64":
                "Fn::Sub": |
                  #!/bin/bash
                  cd /root/
                  apt-get update
                  apt-get -y install awscli
                  aws s3 cp s3://XXXX/XXXX.XXX ~/some location
                  #One can install servers, download wars and deploy at runtime
    AppNode2: 
        Type: AWS::EC2::Instance
        Properties:
            # create another instance
    AppNodeSG: 
        # Security group to give access to ssh and port 80
        Type: AWS::EC2::SecurityGroup
        Properties: 
            GroupDescription: SecurityGroup for new AppNode
            VpcId: vpc-XXXXX
            SecurityGroupIngress:
            - IpProtocol: tcp
              FromPort: 80
              ToPort: 80
              CidrIp: 0.0.0.0/0
            - IpProtocol: tcp
              FromPort: 22
              ToPort: 22
              CidrIp: 0.0.0.0/0
    InstanceProfile:
        Type: AWS::IAM::InstanceProfile
        Properties: 
            Path: /
            Roles: [S3FullAccess] # S3FullAccess Role created Manually, so that my EC2 instance can access S3.