DevOps across two companies (solution provider-solution consumer relationship)

When looking at the current disruptive technologies like Docker and other container virtualization technologies helping developers to be more productive and have enabled the DevOps movement at all in the first place it might be obvious that the focus lied on the agile part in DevOps first. Another objective of this movement certainly is to convince system operators to develop infrastructure code in an agile test-driven and iterative manner. So it is no surprise that other use cases which do not involve the Dev part in DevOps have not been in focus until the time being.

DelOps Approach – Process View

The typical and official build and deployment pipelines start on premise, making it easy to map their output artifacts and their content to an internal infrastructure through plugins, built-in or extension functionalities of the build tool in use. A Nuget package from Microsoft or an EAR file from JBoss are good examples. However, how can volatile contents of third party deliveries from external software suppliers be embedded in the internal DelOps processes in a similar way? Some potential solutions can be found in popular design patterns coming from software engineering. By using the adapter pattern, a DSL (Domain Specific Language) or the transformation approach by XSLT, a standardized processing of volatile content of deliveries can be introduced here. We started an open source initiative as DerSalvador GmbH to create a standard protocol in describing (third-party) package contents. The solution consists essentially of an XML-DSL or JSON-DSL which is designed for generic delivery contents. This DSL is of course extensible according to the specific requirements. It includes not only typical DevOps aspects, but also all business and operating processes such as change and release management, monitoring, security and automated provisioning of infrastructure. The goal is also to integrate these processes into the entire DevOps deployment process in an automated form. For example, an ITIL Standard Change could be automatically detected, the security checks, and the automated UAT test executed, so that a production deployment of external packages could take place in minutes. Nowadays the introduction of a standard change in private banks into production still takes often about 2 days. These bottlenecks are found in companies with a rigid change and release management culture and a DevOps-unfriendly environment.Our DelOps approach can achieve deployment Lead-Times similar to successful Fin-tech Startups even for traditional Private Banks.

DelOps Approach – Architectural View with Docker

the process of adopting DevOps can end up being very painful for those who do not go all out in terms of cultural acceptance and fully transitioning to all the required tools. Throwing in a couple of tools like Jenkins and Git for version control and build automation might be a good first step for continuous integration, but the goal of DevOps is far beyond that.

You can’t keep your application architecture and underlying infrastructure the same as before and hope to achieve a DevOps transition. DevOps requires going all the way in changing your infrastructure, from servers and virtual machines to containers.

Containers bring advantages like portability across the development pipeline, flexibility in using multiple programming languages, decoupling of the host system from the application layer, and better security and fault tolerance. Today, it’s hard to imagine a DevOps team could function without the help of containers. While many organizations dip their toes in container adoption, it requires taking the plunge to transition to containers at every point of development.

Similarly, microservices is a bitter pill to swallow, as it calls for major change to the application layer. Microservices, the practice of breaking down a large application into multiple services that work together, supports DevOps in a big way because developers can independently deploy and manage each service. This helps simplify the management of each service, but as a whole, brings new challenges, as many services need to communicate with each other for the app to function seamlessly. Networking, storage, node replication, service discovery, load balancing and resource allocation all become vital to the app’s function.

2. Prioritizing titles over team structure

Giving everyone a DevOps title doesn’t change anything. The reality is that DevOps is a culture, and not a tool. Implementing DevOps means that you have decided to stop working as large, singular, isolated teams like Dev, IT and QA, and instead work as small, multifunctional teams that collaborate together on a Dev + IT + QA level. DevOps aims to achieve a culture that moves fast because teams are empowered to make decisions about the services they manage — that’s where structure comes into play. Your team should be organized based on the microservices architecture that powers your app. This will help each team that manages a service to become independent and to make decisions on their own without constant external assistance. Remember — you need a fast-moving, empowered team culture, instead of catchy titles.

3. Not securing data in the cloud

Out of the many reasons to prioritize data security, the one that stands out is the tremendous increase in the value of data. Information has always been critical for business success. Now, however, with the rise of data science, a company’s success depends on how much value it can unlock from its data. Simply put, data is an asset, and it is valuable today more than ever.

As you transition from a private data center to the cloud, data security is the first aspect to consider. This means understanding the shared responsibility model for data security in the cloud. The cloud vendor is responsible for the security of the cloud, and you’re responsible for security in the cloud.

Security in the cloud means following robust processes to encrypt your data into ciphertext, and to protect it with an encryption key. Services like Amazon Web Services Key Management Service help enforce this kind of data security. You need to ensure that the cloud vendor’s encryption policies and procedures match the level of security you need for audit and compliance purposes.

Securing your apps and data in the cloud involves a learning curve, but it is essential when you are adopting DevOps and a new way of operating in the cloud.

4. Not decomposing data along with services

For services to perform at their peak and process requests at a rapid pace, the data architecture that powers your application matters. If you simply decompose your app into services, but leave the databases that house your data untouched, the data becomes a bottleneck to performance.