Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Roger Strukhoff, Liz McMillan, Stackify Blog, Pat Romanski

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog, FinTech Journal

@DevOpsSummit: Blog Feed Post

Application Modularization in Testing | @CloudExpo @BlueBox #DevOps

One of the most important best practices in application development is testing

Why Application Modularization Matters: Testing
By Ruben Orduz

Preface
A few weeks ago my colleague PJ Hagerty wrote about driving your existing monolithic application toward a more modular design. This time around I'll dive a little bit deeper into its importance and the benefits of application modularization.

The Case
One of the most important best practices in application development is testing, and more specifically automated and continuous testing. When your application is a monolith with multiple functionalities and responsibilities, automated testing becomes massively unwieldy. To illustrate this issue let's use the following illustration of conceptual (and, admittedly trivial) photo gallery web application:

conceptual photo gallery web application example

Say you want to test Login functionality. After writing some basic testing setup and "plumbing" code, etc., you can start writing tests against the Login functionality. What if you want to test Post Photo functionality? On top of all the testing code for Login functionality now you also need special testing code for Post Photo functionality. How about testing Get Photo functionality? You need all of the above code plus the code to test Get Photo. At this point as you start getting testing failures, you'll be heading down-head first-into the proverbial rabbit hole. You won't know for sure where things are going awry: is the Login functionality failing or the Post Photo functionality or Get Photo functionality? And this is as trivial and straightforward as it gets. Now imagine a real application with more complex and intertwined functionality: a nightmare to maintain, test and develop.

Now, let's imagine the same application with a more modular approach:

conceptual photo gallery web application example with modular approach example

It's worth noting that in this example for the sake of simplicity, the Login module is also the front end your users interact with your application.

In the illustration above, we modularized the application in their own logical models and functionality driving toward what is known in the world of software development as single-responsibility principle. So, let's circle back to testing. Let's say you want to test Get Photo functionality. Now it's substantially easier: you can write tests against the Photo module and mock or stub out all other functionality (namely the Login module), same with Album module and any other modularized components. So now you can not only add automated testing more easily, but it becomes significantly simpler to figure out and fix when things fail-you have complete control over the context, so you'll know if it's a real failure or a false-positive and where those failures come from.

Closing thoughts
Testing is a critical part of your application. It's as critical as having a snazzy UI layer, super fast performance or some insanely clever functionality. Without proper testing you're, figuratively speaking, going off the deep end of technical debt and sooner or later you will have to pay. With a monolith, your testing will be limited, at best and nonexistent at worst. If you want your application to be easily maintainable, simple to work on and add or modify existing functionality with ease, you must drive toward modularization and thus testing.

Read the original blog entry...

More Stories By Blue Box Blog

Founded in 2003 by Jesse Proudman, Blue Box offers Blue Box Cloud—a managed Private Cloud as a Service (PCaaS) product available in both hosted and on-prem versions, powered by OpenStack.

Blue Box employees bring a wealth of diverse, in-depth operational experience to each customer installation of our unique hosted private cloud offering. Think of Blue Box team as your application’s lifeline.

@DevOpsSummit Stories
Docker and Kubernetes are key elements of modern cloud native deployment automations. After building your microservices, common practice is to create docker images and create YAML files to automate the deployment with Docker and Kubernetes. Writing these YAMLs, Dockerfile descriptors are really painful and error prone.Ballerina is a new cloud-native programing language which understands the architecture around it - the compiler is environment aware of microservices directly deployable into infrastructures like Docker and Kubernetes.
At CloudEXPO Silicon Valley, June 24-26, 2019, Digital Transformation (DX) is a major focus with expanded DevOpsSUMMIT and FinTechEXPO programs within the DXWorldEXPO agenda. Successful transformation requires a laser focus on being data-driven and on using all the tools available that enable transformation if they plan to survive over the long term. A total of 88% of Fortune 500 companies from a generation ago are now out of business. Only 12% still survive. Similar percentages are found throughout enterprises of all sizes.
As you know, enterprise IT conversation over the past year have often centered upon the open-source Kubernetes container orchestration system. In fact, Kubernetes has emerged as the key technology -- and even primary platform -- of cloud migrations for a wide variety of organizations. Kubernetes is critical to forward-looking enterprises that continue to push their IT infrastructures toward maximum functionality, scalability, and flexibility. As they do so, IT professionals are also embracing the reality of Serverless architectures, which are critical to developing and operating real-time applications and services. Serverless is particularly important as enterprises of all sizes develop and deploy Internet of Things (IoT) initiatives.
DevOps is under attack because developers don’t want to mess with infrastructure. They will happily own their code into production, but want to use platforms instead of raw automation. That’s changing the landscape that we understand as DevOps with both architecture concepts (CloudNative) and process redefinition (SRE). Rob Hirschfeld’s recent work in Kubernetes operations has led to the conclusion that containers and related platforms have changed the way we should be thinking about DevOps and controlling infrastructure. The rise of Site Reliability Engineering (SRE) is part of that redefinition of operations vs development roles in organizations.
When a company wants to develop an application, it must worry about many aspects: selecting the infrastructure, building the technical stack, defining the storage strategy, configuring networks, setting up monitoring and logging, and on top of that, the company needs to worry about high availability, flexibility, scalability, data processing, machine learning, etc. Going to the cloud infrastructure can help you solving these problems to a level, but what if we have a better way to do things. As a pioneer in serverless notion, Google Cloud offers a complete platform for each of those necessities letting users to just write code, send messages, assign jobs, build models, and gain insights without deploying a single machine. So cloud compute on its own is not enough, we need to think about all of the pieces we need to move architecture from the bottom, up towards the top of the stack. Wi...