Software engineering and developer communities are driving the market for cloud consumption and leading each industry into a new era of software-defined disruption. There are no longer questions about elastic and flexible agile development as the way to innovate and reduce time to market for businesses. Open source software plays a key role in the digital transformation to cloud native and understanding how your business strategy needs to address this next disruption in software development is crucial to the success of your business.
Cloud Native applications are a combination of existing and new software development patterns. The existing patterns are software automation (infrastructure and systems), API integrations, and services oriented architectures. The new cloud native pattern consists of microservices architecture, containerized services, and distributed management and orchestration. The journey towards cloud native has started and many organizations are already testing with this new pattern. To be successful in developing cloud native applications it is important that you prepare for the cloud native journey and understand the impact to your infrastructure.
Preparing for the Journey
The first step in a successful business transformation is setting the vision and the goal for the organization. Many organizations struggle with transformation because they start with the technology first.
Technology is exciting and challenging, but lessons learned from the industry are not to start there, but with your business mission, vision, and your people.
At the outset of the transformation, it is critical to get your leadership, partners, and customers on board with your plans, set clear expectations, and gather feedback often. It is important to over-communicate at this initial stage and ensure that buy-in is strong. As you progress on the cloud native journey, you will need to get the support and cover from your leadership.
The next step is to assemble the right team and break down the vision for the journey into phases or steps that are further decomposed into development actions or sprints. It is critical to evaluate the team member’s strengths and weaknesses against the organizational goals to accomplish your vision and invest upfront in training. Most good ops and engineers are interested in furthering their career with training.
Lastly, evaluate technology choices and plan for technology integration with your existing back office, support, and IT systems including existing processes you have in place as an organization. You will need to work with other organizations across the business to identify skill sets needed and support the training or staff augmentation requirements of the other organizations.
We created a video to help you get into the cloud native mindset here.
Infrastructure Impact
@Cisco has always been focused on being a partner to our customers on their transformations. This has primarily been on the hardware front and focused on technology refreshes and technology advances. This is still very critical in Cloud Native Applications because your software can only differentiate you so much. If everyone is using the Cloud and everyone is using the same services, your service will perform, fail, and be as secure as your competitors. Perhaps your going for “good enough” service offerings, but business need that differentiation and your only get differentiation by taking advantage of the both the cloud native software patterns and latest technology advances in the underlying hardware infrastructure.
When evaluating the impact of infrastructure, it is important to start with the end goal of software defined, automated, and integrated in mind. Software defined is often an industry buzzword, but it is very important to look at your existing network, compute, virtualization, storage, and security solutions from a set of software abstractions that can be programmatically configured (set) and consumed (get). Software defined infrastructure is considered part of the infrastructure services (network, compute, storage, and security) that can be configured for the business services to be deployed into or alternatively, the business can deploy a set of services leveraged these abstraction layers, often called blueprints.
Automated infrastructure is the ability to leverage API’s for provisioning a set of services and configuration primitives that enable abstractions and sets of services that deploy pre-defined sets of configuration and then validates the installation and readiness for the application to be deployed. Automation is key for cloud native, as applications need to be able to configure and re-configure in real time based on a number in inputs. These inputs range from failure states, to user demand, to application performance.
Integrated infrastructure considerations are often a secondary thought; however, they should be part of your initial planning. Many applications have dependencies that are internal to the IT infrastructure (i.e. behind the firewall). These dependencies can be data base related, IT compliance related, OSS related, or BSS related. Often, multiple dependencies are discovered as part of the application composition exercise. When evaluating your existing infrastructure, it is important to look at the integration points that your application dependence services have on the cloud native architecture. Many of these integration points can be abstracted as a set of services and API end points.
@Ciscodevnet focuses on the power of this combination and offers learning labs and training for developing with an API first mentality, the importance of CICD, devops, and opensource investment considerations. Please join the community at developer.cisco.com to begin to learn, code, inspire, and innovate.
Defining Business Services
Once you have prepared your organization for the journey and addressed the infrastructure impact- both existing IT, back office, and cloud native technologies, it is time to define business services for the application(s) you are developing. In general, the best way to define business services is to understand the 4 subsystems for a cloud native architecture:
- Application Composition
- Policy and Event Framework
- Application Delivery
- Common Control and Ops
Cloud Native Architecture Sub-systems
There are several ways to decompose your application, and in general, there is not a specific right or wrong way. The best guideline from experience is start by the looking at the composition of your application from a set of services. Application composition is as much an art as a science. My recommendation is to look as the application composition as a block box with three components:
Application Composition
- Internals of the black box, which consists of the application design leveraging the functions that comprise the application logic.
- North bound interfaces from the black box, which consists of external API interfaces to the customer and external services (external to the your firewall)
- South bound interfaces from the black box, which consists of internal API interfaces to internal services, including OSS and BSS.
The application design (internals of the black box) for cloud native design methodology should be thought of as a set of function calls and dependencies. Each function should be independent of the other functions and operate independently as much a possible. The state and scalability should be completely independent.
Each function needs a defined set of policies and events to enable the scalability and resiliency of the service functionality as well as an independent set of common control and operational primitives that enable the individual function service health and control to be performed independent of the other application functional components. The cloud native application composition can be codified into a Cloud Native Application Blueprint as shown below:
Cloud Native Application Composition Blueprint
As mentioned above, the most complicated aspect of the application composition consist of the external and internal services the application depends on. The business models that leverage the OSS and BSS components need to be evaluated in light of business process and function. Some of these services can be containerized while others are not able to be containerized. How to enable a cloud native application to integrate with the OSS and BSS services should not be overlooked.
In addition, external services, especially from cloud providers, are very common. The top concern experienced in cloud native deployments has to do with the latency between the business application services and the external services consumed by the application services. This latency can often times experience timeouts, packet loss, and delays that cause user experience issues. To address this aspect of your cloud native design, understanding the networking impact of your external interfaces and leveraging DNS and SDN controllers to optimize the routing within the application services is required.
Deploy Business Services
Application deployed must be separate from the composition. Application portability is a key business requirement and one of the more reliability methods to achieve this to decouple the application code from the underlying deployment target.
The following guidelines are based on best practices for application portability:
- Deploying the application into different environments (dev, test, production) each of which can consists of different environments (laptop, server, bare metal, private cloud, or public cloud)
- Deploying to different locations (data center(s), availability zones, geo-location constraints)
- Continuous Integration and Continuous Delivery of the application services across environments, location, and hybrid models to ensure that application and application services are continuously refreshed
Continually improve and optimize performance and scale. Once the basics and some of these underlying issues of the technology are understood, the team can then focus on improvements from a process and technology aspect. Sprints should incorporate user stories to address performance and stability issues. Then deployments can reflect these improvements along with enhancements to the underlying infrastructure, BSS, and OSS aspects.
Join the Community
Join me in Berlin this month at Cisco Live! #ciscoliveemea in the @ciscodevnet zone. I am presenting this topic and lessons learned in DEVNET-1065 Session – register here.
For a full description DevNet and everything we have going on @ciscoliveemea #DevNet zone check out our activity guide.
Thanks Kenneth Owens