No matter where you work in the technical space of software development, you are probably in a hurry to launch the application that you are currently developing.

Your customers can’t wait – accelerate development

Time is money, and when you are on the verge of launching your next killer application time is a scarce resource. Your customers won’t wait forever, and you need to launch your applications as quickly as possible if you want to succeed in the fast-paced tech market.
You might also be pushed internally to keep time to market as fast as possible.
No time to build up internal resources, educate colleagues, gather know-how. You need to be faster than the competition. IT teams have to do more and more nowadays so the pressure is on to manage them smartly.

Common Problems With Launching Applications

The road to your application launch date can be a crooked one, with a lot of turns and even dead ends. This is why it is so important to quickly test each small improvement in one or more test environments before deploying it to the end-user visible production environment. The earlier an error in the application or environment is found the quicker and less effort you need to fix it.
One of the most costly and time-consuming errors are differences between the testing and production environments. They result in the application behaving correctly during testing, but then suddenly misbehaving in production even though the same application version was deployed, and you don’t know what the differences are that lead to the problems. These problems can lead to error messages or catastrophic failures on public facing apps and long-term damage to your reputation.
Another security-focused problem is to keep testing and production environments separate from each other to prevent faulty applications under test to ruin real customer data.
Instead of synchronizing dev/test/production environments manually and duplicate this labor for each step of the process you can automate your work using best practice cloud-based tools. 

Why Should You Move Your Applications To The Cloud?

There may be many different reasons why you may be reluctant to move your application to the cloud. You may be used to the classical way of building and testing applications or fear the migration effort, or you might not have the internal know-how or resources.
However, a well-prepared DevOps team leveraging the potential of the cloud can rapidly manage the deployment of applications without a substantial increase in either manpower or long-term costs. It can make it significantly easier to scale the application later in the process and provide access to helpful auxiliary services.
Unifying the different environments using open-source Docker software container technology helps you leverage the world-wide ecosystem and experience. The more parts of the process that you can automate and integrate, the more efficiently you can build and launch your application.

Whitepaper ‘5 Steps Of Moving Your Applications Successfully To The Cloud’

Migrating to the cloud is a big business decision, so it’s vital to go in with both eyes open. Download our ‘5 Steps Of Moving Your Applications Successfully To The Cloud‘ whitepaper and find out how moving to cloud can help you meet your software and application development goals.

DevOps needs three things: people with the right attitude, shared processes and the right tools. Docker software containers helps solve these challenges and offers a standardized platform for development and operation.

Container from the perspective of the developer

From a web agency perspective, each project places different demands on the target system, such as different versions of programming languages ​​and frameworks. These  combinations must be thoroughly tested during development through Continuous Integration (CI), which is time-consuming and prone to error with traditional systems.
Container virtualization, for example with Docker, helps. Docker uses so-called images, compilations of software to launch individual instances of an app, called containers. Unlike traditional virtual machines, these images do not include an operating system and are therefore lighter and faster. Ideal for continuous integration.
From the perspective of the software developer, it is easy to configure the pipelines with Docker, for example within GitLab CI. The image is specified and the runner takes care of everything else. The application is thus tested encapsulated and requires no additional software on the server.

Container from the perspective of the operator

Docker containers are a standardized and efficient way to package software with everything it needs to run. On the one hand, this helps to minimize external dependencies at runtime, so that the versions of PHP, Java etc. used in the correct version with all required modules, extensions and plugins are not yet to be managed separately on the server.
On the other hand, a change of the application code is exactly the same as a change of the application server: a new version of the container image is automatically built and deployed in the test environment, then the same checked image can be rolled out in the production environment.

The Advantages of Standardizing the Software Containers are Analogous to the Containers in Logistics

• Standardization makes containers more efficient: Just as a container ship transports 21’000 different containers with the same crew, a PaaS-provider can operate hundreds of thousands of containers on various customer infrastructures and cloud providers.
• Containers standardize the handling of contents: in logistics, the pick-up points in the corners are exactly the same whether the contents are liquid, solid or gaseous. In software, entrypoint, list port and storage volumes are defined exactly the same, no matter whether PHP, Java or .NET Core should be executed.
• Container technology is portable, so it works on all infrastructures and vendors just like any other means of transport.

The solution of software logistics is therefore called container orchestration and the most well-known implementation thereof is Kubernetes. It standardizes and automates software operations such as deployment / update, scaling, load-balancing, service discovery, storage volume management, monitoring, backup, distribution of containers to multiple servers and isolation of multiple applications, test environments, teams and / or customers.

So what does that mean for you – should you containerize your application?

There may be many different reasons why you may be reluctant to use Docker or container technology in general. You may be used to the classical way of building and testing applications using traditional VM technology or fear the migration effort, or you might not have the internal know-how or resources. Or you might have a legacy application which isn’t easily transferable or movable to the cloud.
So should you jump on this bandwagon – or to stay with the same terminology – ship?
A well-prepared DevOps team leveraging the potential of container technology can rapidly manage the deployment of applications without a substantial increase in either manpower or long-term costs. Moving your application to the cloud will be way easier using container technology like Docker, Kubernetes or OpenShift.
It can also make it significantly easier to scale the application, provide access to helpful auxiliary services and just in general make it more future-proof. So if you are coming from a legacy application, it probably will pay off in the future to invest resources now to make your application container ready.
Unifying the different environments using open-source Docker software container technology helps you leverage the world-wide ecosystem and experience. The more parts of the process that you can automate and integrate, the more efficiently you can build and launch your application.

Whitepaper ‘5 Steps Of Moving Your Applications Successfully To The Cloud’

If you want to learn more about migrating your applications to the cloud, download our free whitepaper ‘5 Steps Of Moving Your Applications Successfully To The Cloud‘ and find out how moving to the cloud can help you meet your software and application development goals.

DevOps is a common term, but unfortunately as vague as “Cloud”: everyone knows that they want or need it and yet it is not something you can simply order and get delivered.
By DevOps we mean the interdisciplinary cooperation between developers and operators of software in order to deploy the applications quickly and systematically.

Similar to agile software development (e.g. Scrum) – where the “product owner” specifies the next development steps together with the software developers and takes over finished work – this promotes communication between the parties involved and reduces misunderstandings and thus expensive errors.
The promotion of cooperation between developers and operators contrasts with the previous practice of strictly separating these teams – whether for reasons of separation of powers (no access by developers to production data) or because developers and operators had to fulfill different requirement profiles (programming skills, on-call service).
In the meantime, however, a number of findings and proven methods from software development have also arrived in the operating processes:

1. Infrastructure as Code: the description and configuration of infrastructure components using scripts to quickly and reliably automate recurring tasks (e.g. installation of a server or installation/upgrade of an application). Depending on the application and environment, there are different tools – Docker, Ansible, Puppet, SaltStack, etc. – which already have their own frameworks and ecosystems with ready-made building blocks for standard components.
2. Test systems: if the setup of a server is completely automated, this minimizes the effort to create one or more test servers. If developers can use a test server that is the same as a production server, they can find errors before they occur in production.
3. Versioning: if the infrastructure or at least parts of it are mapped in code, it can be managed with well-known code versioning tools (Git, SVN, etc.). This makes it possible to track changes to the infrastructure (“Who changed what when?”, “Why does it suddenly no longer work even though the software hasn’t been changed?”) and to roll back changes completely in case an error should occur.
4. Continuous integration of the infrastructure code: just as the actual application is compiled automatically with each change and tested functionally both component by component and as a whole, the requirements for the infrastructure can also be verified with automated tests. The effects are minimized by detecting an error as early as possible. For example, publishing changes can be blocked if errors occur during testing.

Conversely, experience gained during operation also flows into modern software architectures:

1. Packaging and version management: to ensure that all persons involved speak of the same version of the software throughout the entire quality assurance process from test / development server, acceptance by the product owner, possible external testing / validation (beta, user, UX tests), integration with external interfaces (backends, APIs) to production, the software is stored in a versioned package. The type of packaging can be determined by the development environment (e.g. JAR for Java, WAR for Tomcat) or operating environment (e.g. DEB/RPM for Linux, MSI for Windows), or it can also be independent in the case of Docker. This ensures that the software can be installed and updated completely (with all required libraries) and automates these steps as far as possible.
2. Service Oriented Architectures (SOA) and Microservices: as soon as an application becomes so extensive and/or complex in development that more than a handful of teams take care of it, it is easier to divide the teams into smaller sub-projects (“microservices”) and explicitly define the interfaces between them than to coordinate all teams with each other in the same “project” regarding technology, development progress and internal responsibilities. This not only allows the teams to develop in a decoupled way, but also allows them to choose more suitable technologies for their purpose – provided that the interface to other teams does not change. Ideally, most components / services would be fault-tolerant with each other, i.e. if a sub-component with limited functionality fails, they would continue to function, making the overall project more robust.
3. Configuration Management: most applications have interfaces to other applications – for example to a database or other APIs / services – and write log files. During development, quality assurance testing and production, different endpoints (addresses, credentials, etc.) are used. This allows the isolation of test and production data, so a test of a new version cannot accidentally delete the production customer data. This is why the access data is not managed directly in the code, but in configuration files, which in turn can be generated automatically for each environment or read from environment variables. A modern definition for this is, for example, the twelve-factor method (http://12factor.net/de/).
4. Scalability: applications and services that have clearly defined interfaces can easily be scaled horizontally, i.e. distributed across different servers. This enables the company to offer the service multiple times, redundantly and thus highly available and to react to different loads by adding or removing servers. Even these steps can be automated: It is possible to automatically obtain or release more server resources based on the current load and, depending on the billing model of the individual resources, to produce costs only if the service is also used effectively.

What does the fusion of development methods and operating processes bring in concrete terms?

1. The automation of the infrastructure (see “Infrastructure as Code” above) makes the infrastructure faster, more reliable and prevents inconsistencies due to (missing) manual steps on different systems. It enables developers and product owners to effectively test their results under the same conditions as production.
2. Automating the software lifecycle from development to production makes the whole process faster, more reliable, and can best be done by the product owner himself after the release of the latest version. Thus, after the developers, the operators also give the business the reins for the application into their own hands and are available for further developments. The product owner can thus determine both the scope and the frequency of the deployments. The more frequently a product is rolled out, which means that the scope of the respective changes is smaller, the smaller is the risk of undesirable side effects and errors. If errors nevertheless occur, the product owner himself can reverse the last change and call on the developers to remedy the situation without penalizing the company.
3. Both together prevent IT from blocking the critical path of the project as an end in itself and enable the developers and the business to “self-service”. Of course, this also means a cultural change within a company: if a deployment fails or problems occur in production, then developers and business people have to solve the problem together and make sure that it does not happen again (e.g. by means of automatic testing). It doesn’t matter why or because of whom the problem occurred: no “culprit” has to be found, but the whole process has to be continuously improved.

We at VSHN do nothing all day long but automate different development processes, different technologies, different backends (databases, cache servers, proxies, WAFs, etc.) and operate them according to the requirements of our customers and / or development partners on any infrastructure – be it public clouds such as Amazon, Azure, Cloudscale.ch, Cloudsigma, Exoscale.ch, Safe Swiss Cloud, Swisscom Cloud or private, i.e. company-internal infrastructures on a VMware or Hyper-V basis.
We advise our customers on the location of data storage (CH, EU, international), will soon be ISO27001-certified ourselves and, together with our partners, can offer hosting in accordance with the FINMA standard.
Our core values are trustworthiness and availability of professional competence. Trustworthiness and security through transparency: transparent communication of processes, transparent order definitions and billing models. We work agilely with our clients and communicate regularly. We are available 24×7 around the clock and proactively take care of “our” applications.
We are VSHNeers.