Before software is handed over, it is tested. Before you run it, you want to be sure it‘s doing what it‘s supposed to. But the more agile the process becomes and the more automated it becomes, the faster software is deployed, the less space there is in the process for test- ing. this article shows how testing can be integrated and planned into the agile process from the beginning, so that high-quality results can be delivered.
Software systems are usually constructed so that their function is spread over a set of coupled components. Then, that set of software components forms a logically dependant, but technically isolated, composite, which in it’s entirety forms the application. Such a modular construction of software systems has been an accepted industry standard for some years now and has been grown to new complexity, some might say extremes, with the advent of micro-service architectures.
Adding to the complexity of (multi-tiered) software, application software relies on a number of backend systems behind the application’s “actual backend”, i.e. auxiliary software (message brokers, backup, logging, monitoring) and infrastructure components (that stuff that the application actually runs on, viz. computers, networks, storage systems); and it is – by and large – undisputed that application software cannot run without it(1). For these, distribution of components is de-facto mandatory.
The past – web only
Massive .NET, Java, and PHP-based systems have dominated since the time of the dotcom bubble. Open-source heavyweights, WordPress, Joomla and Drupal, have democratized the creation of simple websites making it accessible to even non-tech users. But this was over 15 years ago – before the arrival of the smartphone and before “the cloud” became the standard for application hosting. Traditional content management systems are web-only monoliths. Rigid and inflexible, they can hardly be adapted for modern digital content channels such as mobile, IoT or AR. Even small, unambitious technical changes lead to long implementation times.
“We have to duplicate our content in the CMS for the web, and the CMS for the mobile app.” – a frequent complaint by marketing professionals. “We are held back by frontend template constraints and only fix bugs and release new customer-facing features in 4-6 month cycles.” – a developer team’s daily struggles.
Cloud, especially when understood as PaaS (Platform-as-a-Service)-approach changes a lot for developers, technologically and in regard to mindset. In fact, it changes so much, that we as developers need to reinvent ourselves – and actually need to bury our old incarnations. this new series will cover all of these aspects and starts by giving a high-level overview on the growing complexities and challenges, developers are confronted with.
When moving into a cloud environment, we could try to execute as we did in the past. This is embraced by lift & shift-approaches, that basically recreate environments existing in traditional datacenters in clouds.
Although this is a viable first step, it should actually be considered as the first step only, since opportunities and challenges in cloud-environments demand completely new approaches in regard to software, operations and integrations. If adjusted to these approaches, the total-cost-of-ownership (TCO) of a software will dramatically reduce while quality of service increases, and time-to-market will lower significantly.
To understand these correlations, we need to see the bigger picture first.
With the merger of Dentsply and Sirona in 2016, the company has become the world’s largest manufacturer of dental products and technologies in the field of dentistry and dental technology. During the past 3 years, Dentsply Sirona managed the multiple transformation of merging over 16.000 employees in over 40 countries into one single company and realizing an unprecedented digitization journey centers around connecting practitioners, patients’ needs and equipment. Julia Hahn and Felix Evert dis- cussed with Jörg Haist, Vice President of Platform Management Equipment & Instruments, how Dentsply Sirona leveraged the opportunities of digital transformation in medical equipment.
Google Cloud has a lot of impressive things to discover – one of the interesting and least known aspects is its integrated build system, Cloud Build. Let’s set it up for hosting a GIt-repository, for building a microservice and for storing the generated artifacts in a Docker registry inside Google Cloud.
First of all, there are some prerequisites to fulfill before using Google Cloud Build:
– Google Cloud account with payment functionality enabled needs to be present
– A Project has to be created inside Google Cloud – our sample project is called cloud-report-project
– The Google Cloud SDK is to be installed on your local machine
If all of these steps are taken, we should have a Microservice we want to build. In this article, we use a Spring Boot based Microservice written in Java (you can find the source code at ), but you can of course use a language of your liking – Google Cloud Build actually does not care about a programming language, it refers to builders being supported on the platform.
How does Google Cloud Build work?
Before building anything, we should understand the basic idea behind Google Cloud Build, since it is different to the approaches AWS or Azure have. Essentially, Google Cloud Build does exactly, what the name supposes: It imports sources, builds them, creates container images, stores and – if requested to – deploys them inside of Google’s own cloud environment.
Less than five years old, Kubernetes has already become the de facto container management system worldwide. In 2018 Forrester’s cloud predictions declared Kubernetes to be the victor in the “war for container orchestration dominance.” Since then its popularity has only continued to grow and CIOs across every sector now consider it tobe the gold standard for container management. In particular when it comes to supporting DevOps within their business.
This popularity is no surprise given the benefits of the technology. Kubernetes groups application containers into logical “packages” for simple, fast management and discovery. It also automates the deployment and scaling of containerised applications. Not quite a true platform in itself, Kubernetes can be combined with additional elements to provide the ease of use of Platform-as-a-Service for developers, with the adaptability of Infrastructure-as-a-Service to make it easier to move workloads across infrastructure providers. Modern enterprise use containers as an increasingly important aspect of their business. But there are still those implementing container technology without Kubernetes. CIOs should consider the following three key reasons to embrace the industry standard…
Rook allows you to run Ceph and other storage backends in Kubernetes with ease. Consumption of storage, especially block and filesystem storage, can be consumed through Kubernetes native ways. this allows users of a Kubernetes cluster to consu- me storage easily as in “any” other standard Kubernetes cluster out there. allowing users to “switch” between any Kubernetes offering to run their containerized appli- cations. Looking at the storage backends such as minio and CockroachDB, this can also potentially reduce costs for you if you use rook to simply run the CockroachDB yourself instead of through your cloud provider.Data and Persistence
Aren’t we all loving the comfort of the cloud? Simple back-up and also sharing of pictures as an example. Ignoring privacy concerns for now when using a company for that, instead of e.g., self hosting, which would be a whole other topic. I love being able to take pictures of my cats, the landscape, and my food and sharing the pictures. Sharing a picture with the world or just your family is only a few clicks away. The best of that, even my mother can do it.