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. 

The benefits of Markdown come from the fact that everything is plain text in the file, without all the extra hidden information that word processors put in the file. This means that:

• Documents can be tracked in the same change tracking system as the application code
• User can focus on writing and let the system deal with the visual formatting
• Single official source of the documentation is stored in the centralized management system
• All changes are tracked in history all the way down to the individual change
• Most markdown editors enablefast, accurate writing.  Additionally, most modern code editors support markdown allowing seamless switching between code and documentation.
• Documentation is versioned alongside the code making it simple to determine if the documentation has been updated with the latest code changes. It also simplifies the creation of release notes as every time a change is made to a document, a comment must be made in the central repository about the nature of the change.
• Easy conversion of markdown content into all major formats like .doc or .pdf  for external distribution is supported by most markdown editors.

While markdown is not the only text mark up solution ( AsciiDoc is another one for example),  it is the de facto industry standard. In fact, there are a number of popular Markdown editors like:

• Byword
• iA Writer
• MKDocs (full documentation site generator)

It is also supported by popular code editors like Visual Studio code , Atom and Pycharm