But how do you prepare for the unexpected? 'Chaos Engineering' has risen in popularity in the last few years as a way to address that exact question. The main premise of this type of engineering entails using software to randomly simulate application, equipment and network failures. This allows teams to build muscle memory on how to handle unexpected failures. Companies like Netflix routinely run chaos engineering in production to train teams to quickly resolve outages. The folks at Gremlin wrote a good introductory article on this subject. 

We all witnessed the meteoric adoption of Zoom and other technologies that enable remote work. However, It was not long ago that most IT managers indicated that setting up the infrastructure to support employees working remotely was a fool's errand. It was too complicated and it would take months, if not years to implement. And then, the pandemic hit. Those same organizations implemented remote work in a matter of weeks

Applying new ideas and technologies comes down to breaking down misconceptions, having strong motivators, not being afraid to test new technologies and having clear goals.

The transition to remote work has not always been smooth given how fast the pandemic forced us to implemented it. However, remote teams have produced great results as long as:

• Managers hold people accountable for work output instead of the numbers of hours clocked.

• Teams make an effort to build a healthy and supportive online community that ensures both work and personal relations continue to flourish.

• Members set clear rules for both personal interactions and work deliverables

This change has been so successful for a large number of IT workers, that the average rent in the Bay Area have already started to drop. Employees have started to move away from the tech hubs since they no longer have to pay a large percentage of their salaries for rent when they can buy a much larger home somewhere else for a fraction of the cost .

Similarly, as organizations grow and the company's needs for technology increase, it is tempting to think that a large portion of the costs are fixed and absolutely unavoidable.

But just like personal spending, organizational spending is not set in stone. As companies grow, expenses grow as well and the expenses are rarely inspected with a calm and unemotional lens (Telling users that their favorite tool will be sunset is always an interesting conversation). But this type of review is absolutely necessary and must take place on a regular basis. Otherwise, companies are eventually forced to take hurried, dramatic cost cutting measures on the next market down turn.

On the other hand, sales at physical stores has been declining faster this quarter than previously expected. For example, the number of store closures so far in 2020 has been reported by Forbes to be over 13,000 compared to 5,700 in 2018. 

The bottom line is that companies without a solid digital transformation plan need to create one right away. And, companies that have based their 5 or 10 year plan on historical consumer trends need to set more aggressive timelines. The era of measuring digital transformation projects in years has come to an abrupt end. The competitive edge belongs to nimble companies capable of adapting quickly. While consumer behavior might shift once the pandemic is over, it will never mirror the original pre-pandemic habits.

The pandemic has changed the way we interact with the world. As a result, there have been significant shifts on the IT landscape. We explored the shifts in terms systems' reliability, employee retention, operation costs and digital transformation. But, that is just the tip of the iceberg. Companies must re-imagine their digital visions and strategies to cope with the new reality. There is an old English saying that seems specially relevant at this point:

An hour may destroy what an age was building

As we adapt to long term lockdowns, masks and other health restrictions, companies must find innovative solutions to push the status quo in order to survive. After all, nothing is permanent in tech beyond change itself.

On a final personal note, I would like to thank all medical personnel that have been fighting the pandemic. They have been at the front lines of the COVID-19 battle, sometimes at great personal cost, to keep the rest of us safe. If you know someone that works at a hospital, doctor's office, lab, etc... take a couple of minutes from your busy life and thank them for their hard work.

What are microservices? 

While there are several definitions of what exactly is a microservice architecture, the basic high level infrastructure is built around small pieces of code with just one responsibility and that perform a single task. Those individual pieces of code are combined to achieve more complex tasks. You can think of it as building blocks. While the individual building blocks cannot do much on their own, they can be used to build grand structures

How do microservices compare to traditional applications?

Traditional applications are built as a single code base. All the pieces are intertwined into a single package which, at a simplified high level, interacts with an end user on one side and the database on the other. Microservices applications are built using a multitude of small codebases that work together to deliver results to the end user. Each microservice could be connected to its own database to manage its own data, though they do not need to be. For example, a simple number adding microservice would receive numbers as inputs and return a result without needing a database.

The clear advantages and reasons why microservices are becoming so popular are:

• Maintainability: Maintaining small pieces of code with few, if any, dependencies is simpler than maintaining a large code base with lots of dependencies

• Reusability: Microservices are small pieces of code with a single purpose in life and can easily be reused in other projects

• Modularity: Since each service is independent of the rest of the application, it can de be upgraded and deployed independently

• Fault isolation: Properly designed microservices isolate issues from the rest of the application

• Scalability: Microservices are scaled independently without scaling the whole application

• Cost: As a corollary to the scalability of microservices, scaling small microservices requires less resources than scaling the whole application. This translates to lower costs, especially in the world of cloud computing, where costs are based on resource usage.

Increased architecture complexity

While individual microservices are significantly less complex than a traditional application, the overall architecture of an application increases significantly in mainly two ways:

• Number of moving parts: Beyond the large number of microservices that need to be maintained, additional software modules are required to allow the microservices to work and perform reliably. In our simple high level overview in figure 1, we introduced a reverse proxy (to allow simple external communication with the external world) and queues (to allow messaging between services). But that is only the tip of the iceberg. We could also introduce logging/monitoring agents, API gateways, secret management and multiple databases among other things.

• Network traffic: In a traditional architecture, applications move data internally and unless the application itself fails, data is guaranteed to be processed. With microservices, that guarantee no longer exists. Communication between microservices is dependent on a network transport across potentially multiple network nodes. Since networks introduce both latency and failures, it is important for the microservices to be built with additional resiliency and the ability to withstand unreachable downstream services. Items like circuit breakers, retries and timeout management become critical for the application to function properly and manage errors gracefully

Microservices architecture opens a world of possibilities when it comes to large distributed systems. It provides a number of significant advantages over traditional monolith architecture. However, like most things in life, it does come with some significant baggage. While this is not a silver bullet, it is a compelling new tool in the software development arsenal. 

Understanding image and containers 

We will use the simple analogy of creating a book to put these two terms in context. The process of writing a book is very similar to the process of creating images and containers:

The original problem that containers solved

In the olden days of application development (which in this fast changing digital world means only a few years ago), each developer would have to waste hours and even days installing all the project tools and libraries in their machines. As more machines needed to be setup, more time (and money) was wasted away in unproductive setup time.

Eventually virtual machines (VMs) came around, and allowed us to create perfect copies of a machine. The copies would include everything needed, from the operating system to the wall paper. This was a significant improvement as only one person would need to create the VM that would be distributed to the team. All was great in the world...for a bit. Soon enough, problems starting appearing. Since VMs are full copies of a machine, the following issues became evident:

• Hard drive space: VMs are so large that businesses had to start buying larger, faster and more expensive hard drives to accommodate them. Even then, machines could not fit more than a couple of VMs. Thus, supporting multiple environments or multiple projects became a real issue

• Start up time: Every time a VM needs to start, it is like starting a whole new machine and we all have gone to get coffee and chat with our colleagues while the OS starts up.

• Resource intensive: Each VM, even if idle, eats a minimum, rather large, set of resources. Most people that have had to juggle multiple VMs will tell you of the time they started a VM by mistake only to find out their machine frozen due to being out of resources

Container Benefits

Environment Setup

• Pre built images: Many software companies have made their solutions available as images from public repositories like docker hub. These images are ready for use and can be used as springboards to create new images. From Python to Tensorflow, these images make it easy and straight forward to get started with a technology. 

• Machine setup: One developer can create the image with all the required software and libraries. The image is then easily sharable through a private repository docker hub

• Environment consistency: Since images are self contained apps, using the wrong version of a library is no longer an issue. Additionally, the image is agnostic of any software installed in the host machine.

• On boarding new members: Since the project image is always up to date, providing new members the latest image ensures their environment is consistent with the rest of the team.

  
  

Application development

• Multi-container environments:

  • It's easy to start up multiple containers at once. Typical example would be to bring up containers for web application, app server and database with just one command.

  • Containers can easily share a common network where they can address each other by name. No need to worry about IP addresses or network protocols.

  • Developer can have all pieces of an application running in their machine, reducing the need to mock up data or mimic calls to a server

• Multiple application versions: It is usual that developers will need to manage multiple versions of an app and related libraries in their machines. This leads to applications not working properly due to the wrong dependencies or the wrong library. Containers solve this issue since they are self contained environments.

• Testing new software: We can experiment with new/trial software within a container and just delete the container once we are done. No need to install the software directly in machine or affect the machine performance by installing too much gunk in it.

• Micro services: While containers are not technically necessary for micro services, they make it easier to develop, deploy and maintain them. With the help of orchestration tools like Kubernetes, managing multiple containerized apps is just a few commands away.

• Serverless: Companies like Amazon and Google pioneered (and marketed) serverless functions to simplify app development. In the backend, these functions run in containers launched on demand

  
  

Application deployment

• Software deployment: Containers are self-contained entities. Pushing the same container from test to production guarantees that the code tested is the same as the code in production. Additionally, pushing code to an environment is as easy as pushing a new container.

• Application rollback: If a deployment goes wrong, rolling back to the previous app version means simply restoring the previous container. No more messy clean ups or leaving behind the wrong library.

• Automation and orchestration: Containers are front and center when it comes to Infrastructure as software (IaS). They enable developers to codify the software and dependencies required by an app. When combined with infrastructure tools as Kubernetes, they allow us to codify both software and hardware needs. This code can then be versioned and stored just like any other software.

Container Challenges

• Using an image: Each image is a bit different depending on how it is built. Thus, they may have some idiosyncrasies on how they are expected to run. Also, caution should be used when using an image from an unknown source

• Management: Containers need to be managed properly like any other code, specially if there are multiple versions of the image deployed or if you are running Microservices

• Change in development flow: Developer workflow needs to be adjusted to the new paradigm and to use new tools more adept to at debugging container based apps.

• Containers overhead: Containers run inside Docker so there is an associated overhead.

• Graphical applications: By design, containers do not include the libraries associated with displaying a GUI. While there are work arounds to this, they are clunky at best. Thus, container based applications expose the GUI through a web browser or a thin client that is installed in the host machine.

Bottom line

Containers change and improve the software development process the same way the cellphone changed how we approach communications, but they are not a silver bullet. Just as we currently live tethered to our cellphone charging cables, containers do come with some constraints. However, the benefits gained in terms agility and portability by far outweigh the costs. Furthermore, containers enable us to move the industry forward and implement/simplify new strategies like micro services and serverless functions. While it may be over kill to use containers for a quick proof of concept (unless you already have an environment setup), they are the best path forward when building enterprise and big data applications.

The basic direction that companies take to deploy their applications on a serverless environment depends on their individual needs and the approach taken for app development. Need a simple set of event driven functions to handle well defined tasks, then go with Cloud functions. More comfortable developing and deploying traditional web applications, then look into App Engine. Want to take advantage of containers and their inherent flexibility to build small to medium applications, then Cloud Run is the way to go. Need further power and control of the way your Kubernetes engine is setup to deal with large traffic coming to your application, then Cloud Run on GKE is the best option. Having all these different options means that project teams have the flexibility to choose the best path to success for their particular situation and their budget restrictions.

Independent of which direction is taken to build/migrate the next successful  application, it is clear that cloud providers are rushing to provide simpler and more powerful, solutions to empower the next generation of developers and applications.

Additional information about Google’s serverless options can be found at https://cloud.google.com/serverless-options/.