Cloud Development

Cloud development is a journey not destination . No matter whether you need machine learning application or mobile application all of them need a cloud backend . Our cloud certified engineers are well versed in AWS,Azure and GCP. We will work with you closely to identify the appropriate journey for your enterprise with optimize the cost and not dissolving agility of your application. We are following an holistic approach to the Cloud centric software development . Its started from the requirement analysis and architectural assessment to production support . The following timeline clearly depicts how we will solutionize and implement your cloud journey.

Discovery

When we move it to the cloud , the first thing we need to understand is your enterprise ready for cloud shift? This is especially needed for your migration project . Our architecture team will assess your existing system and chalk out pros and cons for the cloud movement. We will also identify and document what will be the best public cloud considering your application nature, growth , expansion and ROI . After completion of the architecture assessment we will come with a document with our finding and recommendations . Architecture assessment will vary from 1 week to 4 weeks based on the complexity of the system.

Cloud assessment service is designed to provide you with the data you need to determine which applications and infrastructure can, and should be moved to the cloud. Our proven methodology will provide you with the proper data and cost analysis to configure the optimum cloud configurations, cloud providers, and costs to allow you to make informed decisions on your migration strategy, and understand your cloud Total Cost of Ownership.

Cloud strategy is first and foremost about defining your motivations and goals for adopting cloud. Most enterprises identify two or three of these needs as their primary goals. Once you have identified your goals for adopting a cloud strategy, then you can focus on your requirements.

  • Based on our assessment the cloud strategy is formulated according to our need– Lift and Shift, Re-Factor, Re-Architect, and so on. Based on this we help our client accelerate their cloud adoption journey.
  • Cloud Readiness Analysis Cloud Compatibility Cloud Comparison Application
  • Re-Architecture/Re-Deployment Scenarios Business Case for Cloud Migration to Cloud
  • Apart from the above we are following certain Cloud strategies which are considered to be implemented in order to achieve higher efficiency at the same time maintaining a cost efficient implementation.

Before we start to design application architecture for the cloud, we need to consider the main common quality attributes of the cloud: When designing applications for the cloud, irrespective of the chosen platform, We have often found it useful to consider four specific topics during our initial discussions; scalability, availability, manageability and feasibility. The main aim for us should be to produce an initial high-level design and architecture. This is achieved by considering these four key elements holistically within the domain of the customers project requirements, always remembering to consider the side-effects and trade-offs of any design decision (i.e. what we gain vs. what we lose, or what we make more difficult).

Design

Once we finalized the strategy , the next step is to create the high level design . We need to consider both cloud centric technologies and cloud agnostic technologies . One typical example for that to use lambda/cloud function or virtual machines. Both got pros and cons . In the high level design we define the blue print of application eco system by considering the following design principles.

zDistanceLab Cloud Assessment & Migration help the customers to learn, understand, and migrate to the cloud. This is the initial phase in which we understand our client’s business and determine which cloud strategy is suitable for a scalable, reliable, and cost-effective migration. It provides palpable insights that can be used to determine the significant role of cloud computing in your strategic business and IT plans. This phase suggests an optimal cloud strategy and roadmap based upon an appropriate platform selection Cloud option evaluation and cost benefit analysis.

  • Capacity
  • Platform/Data
  • Load

  • Will we need to scale individual application layers and, if so, how can we achieve this without affecting availability?
  • How quickly will we need to scale individual services?
  • How do we add additional capacity to the application or any part of it?
  • Will the application need to run at scale 24x7, or can we scale-down outside business hours or at weekends for example?

  • Can we work within the constraints of our chosen persistence services while working at scale (database size, transaction throughput, etc.)?
  • How can we partition our data to aid scalability within persistence platform constraints (e.g. maximum database sizes, concurrent request limits, etc.)?
  • How can we ensure we are making efficient and effective use of platform resources? As a rule of thumb, I generally tend towards a design based on many small instances, rather than fewer large ones.
  • Can we collapse tiers to minimize internal network traffic and use of resources, whilst maintaining efficient scalability and future code maintainability?

  • How can we improve the design to avoid contention issues and bottlenecks? For example, can we use queues or a service bus between services in a co-operating producer, competing consumer pattern?
  • Which operations could be handled asynchronously to help balance load at peak times?
  • How could we use the platform features for rate-leveling (e.g. Azure Queues,AWS, Service Bus, etc.)?
  • How could we use the platform features for load-balancing (e.g. Azure Traffic Manager,AWS, Load Balancer, etc.)?

  • What Service Level Agreements (SLA’s) are the products required to meet?
  • Can these SLA’s be met? Do the different cloud services we are planning to use all conform to the levels required?

  • Which parts of the application are most at risk from failure?
  • In which parts of the system would a failure have the most impact?
  • Which parts of the application could benefit from redundancy and failover options?
  • Will data replication services be required?
  • Are we restricted to specific geopolitical areas? If so, are all the services we are planning to use available in those areas?
  • How do we prevent corrupt data from being replicated?
  • Will recovery from a failure put excess pressure on the system? Do we need to implement retry policies and/or a circuit-breaker?

  • In the event of a catastrophic failure, how do we rebuild the system?
  • How much data, if any, is it acceptable to lose in a disaster recovery scenario?
  • How are we handling backups? Do we have a need for backups in addition to data-replication?
  • How do we handle “in-flight” messages and queues in the event of a failure?
  • Are we idempotent? Can we replay messages?
  • Where are we storing our VM images? Do we have a backup?

  • What are the acceptable levels of performance? How can we measure that? What happens if we drop below this level?
  • Can we make any parts of the system asynchronous as an aid to performance?
  • Which parts of the system are the mostly highly contended, and therefore more likely to cause performance issues?
  • Are we likely to hit traffic spikes which may cause performance issues? Can we auto-scale or use queue-centric design to cover for this?

This is clearly a huge topic in itself, Security is always important. First, we need to decide how we’re going to manage access to the cloud. Each cloud provider supplies their own solution for Identity and Account Management (IAM)

There are a few interesting items to explore which relate directly to cloud-computing include:

  • What is the local law and jurisdiction where data is held? Remember to include the countries where failover and metrics data are held too.
  • Is there a requirement for federated security (e.g. ADFS with Azure Active Directory)?
  • Is this to be a hybrid-cloud application? How are we securing the link between our corporate and cloud networks?
  • Encrypt communication between service components.
  • Encrypt all sensitive information.
  • Grant the minimum required access level to the cloud services for your application.
  • Design a solution to rotate encryption keys and credentials.
  • Use virtual private networks and expose only public endpoints to the internet.
  • How do we control access to the administration portal of the cloud provider?
  • How do we restrict access to databases, etc. from other services (e.g. IP Address white-lists, etc.)?
  • How do we handle regular password changes?
  • How does service-decoupling and multi-tenancy affect security?
  • How we will deal with operating system and vendor security patches and updates?

This topic of conversation covers our ability to understand the health and performance of the live system and manage site operations. Some useful cloud specific considerations include:

  • Monitoring
  • Deployment

There are a few interesting items to explore which relate directly to cloud-computing include:

  • How are we planning to monitor the application?
  • Are we going to use off-the-shelf monitoring services or write our own?
  • Where will the monitoring/metrics data be physically stored? Is this in line with data protection policies?
  • How much data will our plans for monitoring produce?
  • How will we access metrics data and logs? Do we have a plan to make this data useable as volumes increase?
  • Is there a requirement for auditing as well as logging?
  • Can we afford to lose some metrics/logging/audit data (i.e. can we use an asynchronous design to “fire and forget” to help aid performance)?
  • Will we need to alter the level of monitoring at runtime?
  • Do we need automated exception reporting?

  • How do we automate the deployment?
  • How do we patch and/or redeploy without disrupting the live system? Can we still meet the SLA’s?
  • How do we check that a deployment was successful?
  • How do we roll-back an unsuccessful deployment?
  • How many environments will we need (e.g. development, test, staging, production) and how will deploy to each of them?
  • Will each environment need separate data storage?
  • Will each environment need to be available 24x7?

When discussing feasibility we consider the ability to deliver and maintain the system, within budgetary and time constraints. Items worth investigating include:

  • Can the SLA’s ever be met (i.e. is there a cloud service provider that can give the uptime guarantees that we need to provide to our customer)?
  • Do we have the necessary skills and experience in-house to design and build cloud applications?
  • Can we build the application to the design we have within budgetary constraints and a timeframe that makes sense to the business?
  • How much will we need to spend on operational costs (cloud providers often have very complex pricing structures)?
  • What can we sensibly reduce (scope, SLAs, resilience)?
  • What trade-offs are we willing to accept?

Development

In the cloud. Development phase we take each individual subsystem in the design and implement in multiple iterations . It follows following sub phases.

Analysis

Analyze the sub system and identify the building software blocks for the components.

Low level Design

Create low level design and that includes connectivity between the components , automated testing and deployment.

Implementation

In this phase we do the actual coding and the perform infrastructure as code as well.

Verification

In this phase we make sure the verification of the implemented code . This will go through multiple iterations . Automated testing and code checks enables fast completion of the phases.

Deployment

In this phase we do the final deployment to the production.

Devops & Continuous Integration

Software and the Internet have transformed the world and its industries, from shopping to entertainment to banking. Software no longer merely supports a business; rather it becomes an integral component of every part of a business. Companies interact with their customers through software delivered as online services or applications and on all sorts of devices. They also use software to increase operational efficiencies by transforming every part of the value chain, such as logistics, communications, and operations. In a similar way that physical goods companies transformed how they design, build, and deliver products using industrial automation throughout the 20th century, companies in today’s world must transform how they build and deliver software.

DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes. This speed enables organizations to better serve their customers and compete more effectively in the market. DevOps as a service moves traditional collaboration to development and operations team to the cloud, where many of the processes can be automated using stackable virtual development tools.

As many organization adapt DevOps and migrate their apps to the cloud, so too will their tools used in build, test, and deployment processes, effectively making continuous delivery itself a managed cloud service. We’ll take a look at what such a move would entail, and what it means for the next generation of DevOps teams.

Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams are merged into a single team where the engineers work across the entire application lifecycle, from development and test to deployment to operations, and develop a range of skills not limited to a single function. In some DevOps models, quality assurance and security teams may also become more tightly integrated with development and operations and throughout the application lifecycle. When security is the focus of everyone on a DevOps team, this is sometimes referred to as DevSecOps. These teams use practices to automate processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required help from other teams, and this further increases a team’s velocity.

  • Speed
  • Rapid Delivery
  • Reliability
  • Scale
  • Improved Collaboration

Under a DevOps model, development and operations teams are no longer “siloed.” Sometimes, these two teams are merged into a single team where the engineers work across the entire application lifecycle, from development and test to deployment to operations, and develop a range of skills not limited to a single function. In some DevOps models, quality assurance and security teams may also become more tightly integrated with development and operations and throughout the application lifecycle. When security is the focus of everyone on a DevOps team, this is sometimes referred to as DevSecOps. These teams use practices to automate processes that historically have been manual and slow. They use a technology stack and tooling which help them operate and evolve applications quickly and reliably. These tools also help engineers independently accomplish tasks (for example, deploying code or provisioning infrastructure) that normally would have required help from other teams, and this further increases a team’s velocity.

Production Support

Cloud made it very easy to deal with how we perform production support . Gone were the days , the engineers works on shifts and make sure nothing is broken in the production system . This is achieved by using 2 techniques Monitoring and Alert mechanism .

Monitoring

For monitoring part we can use cloud centric monitoring system such as cloud watch or proprietary systems like Dynatrace , splunk ,AppDynamics ,New Relic , Datadog etc. We can do log monitoring or we can use application injection monitoring .

We can use the following monitorning services to refine and redefine our end result

  • Availability monitoring of physical and virtual resources – compute, storage and networking
  • Utilization monitoring of CPU, memory, disk space & swap space
  • Traffic monitoring on the internal network interface and internet facing interfaces
  • Monitoring of kernel parameters & predefined stack parameters
  • Security threat monitoring
  • Log monitoring
Alert Mechanism

We can create monitoring alarms in these systems which will fed into the alert tools like. pagerDuty , send grid etc . This will notify the user on text as well as call which can be configured in Multiple escalation levels . ELK (Elastic search , Logstash and Kibana) is good opensource alternative for monitoring and alerting . InfluxDB implementation is a good strategy for metric evel collection and analysis.