VenkatSubramaniam

By their very nature, distributed applications have to communicate. But, how do we exchange data and what are the consequences of choosing one solution over the other, in terms of ease, cost, impact on extensibility, and so much more.

Why talk about resilience when thinking of scale? It turns out all the effort we put in to achieve great performance may be lost if we are not careful with failures. Failure is not only about unavailability of parts of an application to some users, it may result in overall poor performance for everyone else as well.

With the prevalence of distributed systems, server less applications, and microservices, a greater emphasis is placed on asynchronous communication between applications and different parts of applications. One impact of asynchronous programming is scalability.

It almost feels like we keep hearing this chant "Monoliths are bad, Microservices are awesome." When architects, technical leads, and developers reject architecture due to bias or favor due to infatuation organizations lose. The most important question is what are the business needs and which architecture is the most suitable for that.

Creating Microservices is hard and it takes more effort.

Many developers aspire to become architects. Some of us serve currently as architects while the rest of us may hope to become one some day. We all have worked with architects, some good, and some that could be better. What are the traits of a good architect? What are the skills and qualities we should pick to become a very good one?

Creating microservices takes substantial effort but maintaining them in production takes a lot more time, cost, and effort. If we forget some key practices the results can be devastating for the organization and we end up hurting from the lack of the measures we can put in place to proactively address potential issues.

Decisions, decisions, decision, that's our live every day. But, what's worse than making a bad decision is not remembering why we made a decision, good or bad. Architectural Decision Records are highly important to document the decisions we make, to support the decisions, to bring in necessary and sufficient reasons, and to reevaluate decisions when the business requirements and/or the technologies change.

Design Pattern evolve when languages and libraries evolve. There is no shortage of patterns but finding which one to apply, why, and how is a challenge.

Big up front design is discouraged in agile development. However, we know that architecture plays a significant part in software systems. Evolving architecture during the development of an application seems to be a risky business.

A number of agile teams expect their technical staff to be cross functional and carry multiple responsibilities. In general that is good, however, there's still a significant role for an architect.