Why Java still matters

With the release of Java 21, the conversation on the relevance of the venerable programming language restarted. But a more important question remains, does Java still matter?

Photo by Mike Kenneally on Unsplash

What announcement would you like to see in Java 21 that would make you excited? Well, for most people, actually nothing. Because, you know, what's exciting with a predictable, slow-paced, stable, widely adopted enterprise programming language?

Read to find out.

A little bit of Java History

Java was originally developed by James Gosling at Sun Microsystems in 1991. The goal was to develop a small, reliable, portable, distributed, real-time operating platform. The language was initially called Oak, later renamed to Green and finally renamed Java, from Java coffee, a type of coffee from Indonesia.

Officially released in 1995, Java quickly became popular for developing web applications. The Java Virtual Machine (JVM) allowed Java code to run on any platform that had a JVM, which made it a very versatile language. Java is also a very secure language, which made it a good choice for developing web applications.

Key events in Java's history

For brevity, here are some of the key events in the history of Java:

• 1991: James Gosling starts the Java project at Sun Microsystems.
• 1995: Java 1.0 is released.
• 1996: Java becomes a popular language for developing web applications.
• 1998: Java 1.1 is released, adding new features such as garbage collection and threads.
• 2000: Java 1.2 is released, adding new features such as swing and applets.
• 2004: Java 5 is released, adding new features such as generics and annotations.
• 2009: Java 6 is released, adding new features such as concurrency improvements and a new security manager.
• 2014: Java 8 is released, adding new features such as lambda expressions and streams.
• 2017: Java 9 is released, adding new features such as modules and a new garbage collector.
• 2018: Java 10 is released, adding new features such as a new date and time API.
• 2019: Java 11 is released, adding new features such as a new HTTP client and a new text block literal.
• 2020: Java 12 is released, adding new features such as switch expressions and sealed classes.
• 2021: Java 13 is released, adding new features such as text blocks and pattern matching.
• 2022: Java 14 is released, adding new features such as sealed interfaces and record classes.
• 2023: Java 21 is released.

Looks like a pretty good cadence for a 30 year old programming language.

Applications

So where does Java run? Well, these days Java runs pretty much everywhere:

Enterprise Application Development

Java is commonly used to build large-scale, mission-critical applications for business operations. These applications can include customer relationship management (CRM) systems, enterprise resource planning (ERP) software, and supply chain management solutions.

Web Development

Java is used to build robust and scalable web applications. Companies often use Java-based frameworks like Spring and JavaServer Faces (JSF) to create web applications that handle high traffic loads, such as e-commerce websites and online banking platforms.

Mobile App Development

Java is one of the primary languages used for Android app development. Many Fortune 1000 companies develop Android applications for their customers, employees, or partners

Big Data and Analytics

Java is used in big data processing and analytics applications. Companies leverage Java libraries and frameworks, such as Apache Hadoop and Apache Spark, to analyze large volumes of data and gain insights for decision-making.

Middleware and Integration

Java is often used to develop middleware components and integration solutions. These components help connect various software systems and applications within an organization, enabling data flow and communication between them.

Cloud Services

Java is used to develop and run applications on cloud platforms like AWS, Azure and GCP. Java-based microservices and containers are common in cloud-native architectures.

Internet of Things (IoT)

Java can be used to develop IoT applications and solutions. It's used to create firmware for IoT devices and build backend systems that collect and process data from these devices.

Security

Java's security features are essential for companies. It's used in developing secure authentication systems, encryption algorithms, and secure communication protocols to protect sensitive data.

Financial Services

Many large financial institutions rely on Java for their trading platforms, risk management systems, and banking applications due to Java's performance and reliability.

Customer Support

Java is used to develop customer support systems, including chatbots and helpdesk applications, to improve customer service and streamline support operations.

Supply Chain and Logistics

Companies use Java to build applications that manage and optimize their supply chain, inventory, and logistics operations, helping them reduce costs and improve efficiency.

Content Management Systems (CMS)

Java-based CMS platforms are used for managing and delivering digital content on websites and other digital platforms.

E-commerce

Java is frequently used for developing e-commerce platforms, shopping carts, and payment processing systems to support online sales operations.

Data Warehousing

Java is used in the development of data warehousing solutions that enable companies to store, process, and retrieve large volumes of structured and unstructured data for analysis and reporting.

What's new in Java 21

Finally, let's jump into Java 21 (released in September 2023). The release adds many interesting features are being added to the language including:

• Virtual Threads: Virtual threads are a new lightweight threading abstraction that can be used to improve the performance of multithreaded applications.
• Record Patterns: Record patterns are a new feature that can be used to deconstruct record values in a more concise and readable way.
• Pattern Matching for switch: Pattern matching for switch is a new feature that can be used to match values in a switch statement in a more concise and readable way.
• Sequenced Collections: Sequenced collections are a new type of collection that provides direct access to the first and last elements of the collection.
• String Templates: String templates are a new feature that can be used to simplify the process of string formatting and manipulation.
• Unnamed Classes and Instance main() Methods: Unnamed classes and instance main() methods are preview features that can be used to simplify the code for small, self-contained classes and methods.

Does Java still matter?

But the question remains: does Java still matter? Well, given the extensive reach and adoption of the language, the answer is of course, a lot!

But in case you are still not convinced, here are some reasons why Java still matters:

• Popularity: Java is still a very popular programming language today. It is used by millions of developers around the world and is the language of choice for many large and complex applications.
• Portability: Java code can run on any platform that has a Java Virtual Machine (JVM). This makes it a very versatile language that can be used to develop applications for a wide range of devices.
• Robustness: Java is a very robust language that is designed to be secure and reliable. It has a number of features that help to prevent errors and crashes, such as garbage collection and exception handling.
• Performance: Java code can be very performant, especially when it is compiled to native code. This makes it a good choice for developing high-performance applications.
• Enterprise adoption: Java is by far the most popular language of the enterprise. And that's not changing anytime soon.
• Community: Java has a large and active community of developers. This means that there are plenty of resources available to help you learn and use the language.
• Tooling: There are a wide variety of tools available for Java development, including IDEs, debuggers, and code quality tools. This makes it easy to develop and debug Java code.
• Ubiquity: Java is everywhere. Java runs anywhere.

What the future holds for Java

Despite the apparent slowness in adhering to new trends, Java is an actively evolving language. Each new version adds new features and improvements, making Java a powerful and versatile language that is still relevant today.

Those who complain that Java is slow don't understand successful products and enterprise software. This cadence is required when your solutions run on billions of devices, process billions of dollars in financial transactions, and support 5-9's SLA. How simple do you think that is?

Conclusion

In summary, don't let the doomers convince you. Java still matters!

And in case it helps, here's one reason to (re)consider Java: Java is not going away anytime soon. I predict at least another 20 years of strong support for Java. So for those that like a stable language, a great ecosystem, no shortage of work, a great salary and a great career should consider learning and working with the language.

How to transition from Software Development to Architecture

Transitioning from software development to software architecture could be a great career progression for experienced developers. Learn how.

Photo by Brendan Church on Unsplash

When looking for the next step in their career, senior software engineers (or tech leads) have usually three paths before them: become increasingly more technical (aka. principal/staff engineer), move to a managerial position (Head of Engineering, Engineering Manager) or become a Software/Solution Architect.

In this blog post, we will explore how developers can successfully transition from software development into architecture.

What's required from an Architect

Before deciding if you really want to become a Software/Solution Architect, I recommend investing a decent amount of time reading about the role and comprehending everything that's expected from an architect in the context of a technology project (it's a lot!).

That said, transitioning from software development into architecture may not be the natural progression for most developers. While software development focuses on coding and implementation, software architecture takes a broader view, encompassing system design, scalability, long-term planning, a lot of communication and a lot of interpersonal skills. Not everyone will fill those gaps.

That said, the transition will be hard for most, especially for introverts, as it will require a shift in mindset, a huge ramp up to learn new skills and a growing focus on developing soft skills. Not everyone will be comfortable with that.

Transitioning from Development to Architecture

But if you are one of the brave ones who aspire to move into architecture, I have prepared this guide to help. So let's review the essential steps to help you successfully transition from software development into architecture.

1. Understand the Role of a Software Architect

Before embarking on the transition, it's crucial to understand the responsibilities and expectations of a software architect. A software architect is responsible for designing the overall structure of a software system, including making high-level decisions around the technology stack, system components, and interaction patterns. Architects need to balance technical considerations with business goals, scalability, maintainability, and performance.

I've spoken in detail about what's expected from a modern Solution/Software architect in a previous article, please read it here.

2. Expand Your Technical Knowledge

To become a successful software architect, you will need a much broader understanding of technology. This includes learning new technologies, frameworks, design patterns, cloud, tools, databases, keeping up with modern trends (like AI, IoT and Crypto), and gradually understand different technologies in different domains.

You will also be required to learn about best practices, scalability techniques, regulations, security, compliance and industry standards. This broad technical expertise will be immensely valuable when assessing the trade offs or your decisions, which will have a huge impact in your architectural decisions.

3. Enhance Your System Thinking

Transitioning to software architecture requires a shift from code-centric thinking to system-centric thinking. You will have to start viewing software systems as a single unit, learn to zoom out from the code/unit level and understand how different components and dependencies of a solution interact with each other.

You will be required to go much deeper (and wider) by assessing which programming language, database, cloud platform, and architectural style (ie., microservices, event-driven architecture, and domain-driven design) will fit better in your solution.

You will have to consider scalability, fault tolerance, performance, security, and other non-functional requirements. Develop the ability to break down complex problems into manageable components and design solutions that meet the system's architectural goals.

4. Gain Experience in Designing and Documenting Architectures

Additionally, it will be necessary to practice your architectural skills, a lot! Seek opportunities to design software systems, collaborate with colleagues or contribute to open-source projects that involve architecture discussions.

Practice documenting your design decisions, architectural diagrams, and system documentation. By going through the process of design and documentation, you will gain experience in communicating your architectural vision effectively.

Architectural Katas are a great resource for you to practice your skills.

5. Develop Soft Skills

Software architects not only design systems but also collaborate with stakeholders, developers, and project managers. Effective communication, leadership, and negotiation skills are vital for successful architecture transitions.

You will be required to grow your ability to express complex ideas concisely, listen actively, and adapt your communication style to different audiences. Cultivate your leadership skills by taking initiatives, guiding discussions, and mentoring other developers.

6. Seek Mentorship and Learning Opportunities

Learning from experienced software architects can greatly accelerate your transition. Seek mentorship from architects in your organization or join professional communities, forums, or meetups where you can connect with architecture practitioners.

Engage in conversations, ask questions, and learn from their experiences. Additionally, attend conferences, workshops, or online courses that focus on software architecture to deepen your knowledge and expand your network.

7. Embrace Continuous Learning

Software architecture is an ever-evolving field, with new technologies and approaches emerging constantly. Stay up-to-date with industry trends, read books, follow architecture blogs, and engage in discussions on social media platforms. Embrace a growth mindset and continuously learn and adapt to new technologies and architectural paradigms.

Given the extensive technical and non-technical skills required from a modern architect, we prepared this detailed guide describing what our architects should know, and guide them on the learnings they’ll need while working on their professional development plan.

Final Thoughts

Transitioning from software development to software architecture is an exciting career progression that requires a shift in mindset and the acquisition of new skills. By understanding the role of a software architect, expanding your technical knowledge, enhancing system thinking, practicing design and documentation, developing soft skills, seeking mentorship, and embracing continuous learning, you can successfully make this transition.

Remember, becoming a proficient software architect takes time and experience, so be patient and persistent in your journey. Good luck!

See Also

• The modern Solution/Software Architect
• Different Types of Architects
• The importance of onboarding for tech employees
• My Journey to 1 Million Articles Read

Different Types of IT Architects

There is a lot of ambiguity and even misinformation regarding the role of an IT Architect in a software project. Let's understand the differences between them.

Photo by Medienstürmer on Unsplash

There is a lot of ambiguity and even misinformation regarding the role of an IT Architect with regards to their participation in software projects.

Since the responsibilities of an IT Architect differ between organizations, I prepared this article to explain the particularities of different architecture roles, and bring clarity to those looking to work as professional IT Architects.

How Architecture varies per organization 

Due to differences in scale, complexity and organizational structure, Software Architecture varies significantly between small and large organizations.

Usually, large Enterprises have a more structured model for Architecture, and it's common to have a clear distinction between the different roles. In those organizations, it’s common to have different individuals performing different (and more specific) roles, with their titles aligning to their duties. Most of them, you will see in this article.

In smaller organizations though, very commonly Architects end up performing a combination of all of these roles (if not all at the same time for a given project). The name of the roles varies per organization, with the most popular being Solution, Cloud, Technical or Software Architects.

However, regardless of the size of the organization, architects are expected to do much more that just performing the tasks described in the job descriptions.

Which is why architects should broaden their skills as much as possible in different domains. Tough task, but will get you prepared to anything your employer (and clients) request from you. Make this a marathon, not a sprint.

With that said, let’s review the differences between the main types of architects as it relates to projects in technology.

Different types of Architects

Let's jump directly to the most common roles in architecture. Currently in the marketplace, they are:

• Enterprise architect
• Solution architect
• Software/Application architect
• Data/Information architect
• Security architect
• Cloud architect
• Technical Architect
• Principal Architect

So let’s review them.

Enterprise Architect

Enterprise architects are responsible for the technical solutions and strategic direction of an organization. They must work with a variety of stakeholders to understand an organization's market, customers, products, business domain, requirements, and technology.

From a broad perspective, enterprise architects are the most business oriented, and consequently, less technical in nature.

Solution Architect

A solution architect converts business/technical requirements into a solution architecture. They work closely with business analysts, product owners and technical people to understand the requirements in depth, so that they can design a solution that satisfies those requirements.

Solution Architects are the most hybrid role in this list. Solution architects are required to have great technical and business skill, making them a perfect fit for any project in technology.

Software (Application) Architect

Software/Application Architects focus mainly on the software architecture. They ensure that the requirements for their application are satisfied by the design of that application and serve as a liaison between the technical and non-technical staff working on an application.

Application Architects are involved in all the steps in the software development process.

Software/Application Architects architect and recommend solutions for new/existing/legacy technologies, as well as evaluating alternative approaches to problems and proposing solutions to existing problems.

Data (Information) Architect

Data Architects are responsible for designing, deploying, and managing an organization's data architecture.

Data Architects usually focus on data management systems, and their goal is to ensure that the appropriate consumers of an organization's data have access to the data in the right place at the right time.

Lastly, Data Architects are responsible for all of an organization's data sources, both internal and external. They ensure that an organization's strategic data requirements are met.

Infrastructure Architect

Infrastructure Architects focus on the design and implementation of an organization's enterprise infrastructure. This type of Architect is responsible for the infrastructure environment meeting the organization's business goals, and provide hardware, networking, operating system, and software solutions to satisfy them.

Security Architect

A Security Architect is responsible for an organization's computer and network security. They build, oversee, and maintain an organization's security implementations.

Security Architects must have a full understanding of an organization's systems and infrastructure so that they can design secure systems.

Cloud Architect

A Cloud Architect is someone who is responsible for an organization's cloud computing strategy and initiatives. They are responsible for the cloud architecture used for the deployment of software systems. An organization that has someone who is focused on cloud architecture leads to increased levels of success with cloud adoption.

The responsibilities of cloud architects include selecting a cloud provider and selecting the model (for example, SaaS, PaaS, or IaaS) that is most appropriate for the organization's needs.

Cloud Architects create cloud migration plans for existing applications not already in the cloud, including the coordination of the adoption process. They may also be involved in designing new cloud-native applications that are built from the ground up for the cloud.

Technical Architect

Technical Architects are another very technical role in Architecture. They develop the technical strategy for a project, making sure that the technical solutions meet the requirements of the customer and the business.

Technical Architects are also responsible for the long-term technical vision of a software solution. They evaluate new technologies and architectures to ensure the system meets the customer’s needs and is cost effective. Additionally, they are responsible for the development and implementation of standards and procedures to ensure the quality of the solutions.

Technical architects are very similar to Application/Software architects. Most likely, most people wouldn’t be able to differentiate them.

Principal Architect

Finally, Principal (or Lead) Architect. This role is usually more related to the leadership performed by the person (in this case, an Architect), than to specific tasks. However, it's expected that the Principal (or Lead) Architect usually possesses the widest knowledge within the team including Solution, Enterprise, Software and Cloud architecture.

Principal Architects frequently oversee and lead the design and development of projects from both a technical and managerial standpoint. Common tasks attributed to them include project leadership, design, planning, governance, team and client engagement.

Finally, principal Architects are expected to have exceptional technical, inter-personal, management, executive and sales skills. After all, they usually interact with a high level audience, including C-level executives.

Conclusion

On this article we presented a quick overview of the different types of IT Architects. Due to differences in scale, complexity, organizational structure and even how roles are defined, Architecture in the context of technology can (and will) vary significantly between organizations.

However, regardless of the role you execute in your organization, keep your skills sharpened by broadening your knowledge as much as you can in different domains. Tough task, but will get you prepared to anything your employer (and/or clients) request from you.

See Also

• How to transition from Software Development into Architecture
• The modern Solution/Software Architect
• The importance of onboarding for tech employees
• My Journey to 1 Million Articles Read

The modern Solution/Software Architect

Understand what's required from modern Solution/Software Architects and learn why being one is much more complicated than you think 

Photo by Rodeo Project Management Software on Unsplash

Being a modern day Solution/Software Architect is much more complicated than you might think. On this article let's review the nuances of the role(s) and in which understand domains one should excel to be a successful modern day architect.

Solution Architects and Software Architects are not the same role. But because the guidelines listed on this article serve perfectly for both, for the purposes of this article, allow me to refer to both as simply, the Architect.

Apparently, there's a lot of confusion and ambiguity with regards to the Architecture role. Differently of most people think, an Architect is not an upscaled tech-lead or a principal engineer. In fact, the goals of each roles are so different that together, the Architect and a their technical counterparts make a great team.

With that said, allow me to introduce you to the Architect role.

Who is the Architect?

Architects are a hybrid of technical and executive. Which means that in order to be successful at their jobs they should have strong technical, communication, executive and interpersonal skills.

Architects are not expected to know every detail of a software component or every possible argument to Your-Favourite-CLI. But they should know enough to be able to evaluate the tradeoffs of each alternative, choose and detail how a particular technology is used, and most importantly why.

For that to happen, it is recommended that Architects prioritize to go wide and not deep (sorry, you can't do both). Wide in diversity of technology, frameworks, patterns and practices is preferred to deeply knowing how one technology works (which's what the Engineer is supposed to do). So having experience with a diversified portfolio of technologies is strongly recommended.

Additionally, the Architect should not act as a sales representative of a particular technology/cloud service provider. Their choices should always favour business decisions first and foremost.

The modern day Architect

With a lot of competition, AI, a plethora of technologies and faster than ever changes in the business marketplace, how can one keep up to date with so much? This is where the modern day Architect comes in. 

Modern day architects must be strong in technical and non-technical domains.

But because the modern day Architect being required to know so much and master many different domains, the first thing they should learn is how to prioritize what they'll work on. Make your goals SMART so they are prioritized, specific, measured and acted upon.

But remember that the fallacy that an Architect is purely technical has to be deconstructed. The modern day Architect should be technically strong while also possessing sufficient interpersonal skills to be able to lead teams, handle difficult conversations and interact with a diverse audience ranging from business executives, boards, RFPs to technical teams.

So let's review both domains.

Technical Skills

Software Design and Architecture

The modern software architect needs to be intimately familiar with software design principles and patterns, and be able to create efficient architectures that scale and can be easily maintained.

There is just so much here that the best way to address this is on another post. For now, let's summarize it to design + architecture + enterprise patterns, along with excellent

Development

Being able to program in a range of programming languages is essential for the modern Architect. Architects should be familiar with the syntax and features of the languages they work with, as well as the programming frameworks associated with them.

This should be a trivial one if you come from a development background. However, I'd like to add two things. First, beyond excellent programming skills, software architecture and design is crucial for the Architect role. Next, scripting (ex. Bash, Python or PowerShell) is also important as it's also needed by the DevSecOps area of expertise (see next).

Cloud Computing

Cloud computing includes a broad set of technologies that modern software architectures rely on, and a critical domain that the modern day Architect should be be well-versed in.

With the omnipresence of the cloud, make sure you have your cloud fundamentals right. On top of that, add the different facets of cloud (private, hybrid, multi) and complement all of that with architecture skills.

Sound complicated? Indeed. In fact, being a successful Architect that understands well the cloud (in all of its flavours) is much more than one may think. Especially because no certification can measure so much.

DevSecOps

Next, DevSecOps. Yes, DevOps + Security shifted left. The modern-day Architect should have strong fundamentals in everything from basic CI/CD pipelines to Kubernetes, as they'll need to engage frequently with engineers and business to make sure their solutions are modelled and work as expected.

Understanding of DevOps and Continuous Delivery are important for modern software architectures, and the modern software architect must be able to design and implement systems that use these technologies.

Data

Modern architects should have a deep understanding on data and related technologies. That includes data design, storage, analytics, security and governance.

Infrastructure

Modern architects should know enough infrastructure to help they clients wherever they are in their journey. That includes a solid understanding of virtualization, networking, containerization, monitoring, logging and infrastructure automation.

Security

Security is a moving target and a very difficult domain to master. Modern architects should know enough security to be able to understand, adopt security and communicate security to different stakeholders.

Governance and Compliance

Lastly, the modern architect should know enough on Governance, Privacy and Compliance. That includes standards, legislations and regulations as they have a profound impact on the business and on the final solution.

Interpersonal Skills

For an Architect, interpersonal skills are as important as the technical ones. Let's see the main ones.

Communication

Being able to effectively communicate with others is essential for the Architect. This includes ability to actively listen, clear communication, constructive feedback and be able to handle difficult conversations.

Communication is a critical skill for Architects as much of what their work - communicate their ideas and designs to other stakeholders - requires clear communication and must be done effectively.

Presentation and Public Speaking

Architects should be have strong presentation and public speaking skills, as they'll have to communicate to different audiences, both technical and executive.

Leadership

An Architect must have the ability to lead a team and guide them to achieve the project's goals. Part of the expectations include setting expectations, giving directions, and motivating peers.

Problem Solving

As part of their role, Architects must be able to analyze complex situations and come up with creative solutions. In this area, skills such as assessing the pros/cons of each alternative, balancing tradeoffs have to be counterbalanced with technical and business-specific requirements.

Negotiation

Negotiation is a critical skill for Architects as they have to negotiate all the time with vendors, customers, and other stakeholders to successfully achieve the project's goals.

Adaptability

Projects change all the time. Architects must be able to adjust to changing conditions and respond quickly to new challenges.

Emotional Intelligence

Executives must have the ability to read and understand the emotions of others and respond appropriately.

Networking

Architects must be able to connect to different stakeholders to build relationships with different types of professionals that help them make their projects successful.

Final Thoughts

Despite not being exactly the same, this article covered the general characteristics Solution/Software Architects should have to be successful in their hole.

As you may have realized, being a modern Solution/Software Architect is much more complex that one might think and involves being a hybrid tech-executive that takes a lot of time to master.

Hopefully this summary serves as a roadmap so you can guide your career to the level expected by the market when it comes to software/solution architecture.

Good luck!

See Also

• How to transition from Software Development into Architecture
• Different Types of Architects
• The importance of onboarding for tech employees
• My Journey to 1 Million Articles Read

My Journey to 1 Million Articles Read

Writing a tech blog is a fun and rewarding experience. On this article, I will share what I learned after publishing more than 100 articles during the last 5 years

Photo: Christopher Gower on Unsplash

I have been working with technology for more than two decades now. As an avid reader and a tech enthusiast, having my own professional blog is one of the best ways to share what I learn and to give back to the community.

In this article, I will review my experience as a blogger after 5 years of work and more than 100 articles published.

The beginning

As most blogs, this one started off small. During the first year it had no more than a few page views per day. Personally that didn't mattered as my my goal was never to make it a successful product. For me, it was a tool to share what I learned with a greater audience and hopefully inspire others to be better at their jobs.

Little did I know how incredible this journey would eventually become...

As I persisted on the work and wrote more (and better) articles, SEO started to pick up. It didn't take long for this blog to gain traction, be quoted, linked to, and even referenced by search engines on specific queries.

Today

Today the blog has surpassed half-million visits and just keeps growing. On peak days, it has more than 10k visits. What an achievement for such an unpretentious work!

However, for different reasons I can't write as frequently as I would like to. But still, having this channel to communicate to a wider audience inspires me to keep working on it. And I'm not stopping any time soon!

What I learned

So what did I learn during this time?

First off, writing a technical article is no simple task. I usually spend a decent amount of time researching the topic in question before writing the very first sentence. During this phase, I collect as much information as I can, to then organize my thoughts in order to convey the message in a meaningful way. During writing, I carefully enrich my articles with the most relevant material to make the reading experience as fulfilling as possible.

Second, blogging requires a great deal of personal commitment. Be prepared to dedicate a significant amount of your personal time on it. I write most of my articles during my leisure time which may be a concern for some. But rest assured, the benefits definitely outweigh the drawbacks!

Third, persistency is key. For any work to thrive, it's important to have a solid goal and stick to it. Improvement is exhausting. It’s okay to enjoy when you don’t excel. Stick to your plan and don't give up!

Finally, the benefits for you, the writer, are much bigger than you think. Here are some of the benefits I realized during this time:

• You have the chance to help others
• You connect with the community and build great relationships
• You get more prolific technically. Meaning that you'll increase your productivity, confidence, improve your problem solving skills and consequently achieve better output in your work
• You can translate your ideas into paper more quickly and with greater clarity
• You end up writing and communicating better - which are great assets for your professional progression!
• You learn and retain more on the topic discussed
• Depending on how deeply you explore a particular topic, you can eventually become an SME on it.
• And of course, with all of that, greater professional opportunities will come.

What next?

As I prepare for the next 5 years and continue on my journey to reach 1 million articles read, this blog remains an exceptional avenue for inspiration and experimentation.

Starting today, my focus shifts to the challenges, practices, trends, technologies and complexities of the enterprise. And the reason is simple: there is now a rich ecosystem of tooling and documentation ready to address technical requirements with little customization while the most important part − focus on business and customer needs − remains obscure and in second plan for most.

Final Thoughts

Hopefully at this point you understand how a professional blog could help your career. Despite requiring some personal commitment, for me, keeping this blog alive has been an amazing journey and I’m excited to keep working on it for as long as I can.

I hope this article inspires you too on any meaningful work to help those around you.

Further Reading

To celebrate this important milestone, I've listed below some of the articles that I loved writing during the last 5 years. Some of them may not be as recent but still, there's always something that you can learn from it.

Architecture

• How to transition from Software Development into Architecture
• The modern Solution/Software Architect
• Different Types of Architects
• The importance of onboarding for tech employees
• Microservices in ASP.NET
• Docker and Containers, everything you should know
• 5 alternatives to Docker Hub
• Why every developer needs to learn Docker and Containers
• Distributed caching in ASP.NET Core using Redis, MongoDB and Docker
• Non-technical skills for developers

Software Development

• Distributed caching in ASP.NET Core using Redis, MongoDB and Docker
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• Adding Application Insights to a ASP.NET Core website
• Creating ASP.NET Core websites with Docker
• Accessing Entity Framework context on the background on .NET Core
• Getting Enum descriptions using C#
• How to Import CSVs with .NET Core and C#
• MassTransit, a real alternative to NServiceBus?
• Configuration in .NET Core console applications
• Send emails from ASP.NET Core websites using SendGrid and Azure
• How to copy data between Azure databases
• How to enable ASP.NET error pages using Azure Serial Console

Development Methodology

• Definition of Ready
• Interview questions for QA analysts
• Hosting NuGet packages on GitHub
• Hosting Docker images on GitHub

General Technology

• An in depth review of the RavenDB Cloud
• Why you should use the terminal
• Vimium, the hacker's browser
• The Raspberry Pi 4 is here!

Open-Source

• Why I use Fedora
• Why use Vim
• How I fell in love with i3
• How to create a Ubuntu Desktop on Azure
• 20 tips to manage Linux VMs on Azure
• Windows Subsystem for Linux, the best way to learn Linux on Windows
• 5 tools for Azure Development on Linux

Security

• How and why use stronger passwords
• Security and Ethics
• Security Boundaries
• Web Development best practices: 9 tips for stronger passwords
• Integrated security vulnerability alerts on GitHub - Why it matters
• Security is only as strong as your weakest node
• Security and development: how much is being done?

And much more!

There's much more to explore! Feel free to search topics of your interest or use the tags to find what's in there for the topics that interest you.

📫 Reaching out...

Lastly, if you have any questions, don't hesitate to reach out to me on Twitter and/or LinkedIn 😊

Stress test your cloud applications with Azure Chaos Studio

Azure Chaos Studio makes it possible to stress test your applications directly from Azure, and can significantly help in your business continuity and disaster recovery (BCDR) strategies.

Source: Azure

Azure Chaos Studio is a new service in Azure that allows you to test and improve the reliability of your applications. With it, teams can quickly identify weak spots in their architecture, addressing the enterprise goals of business continuity and disaster recovery (BCDR).

Subjecting applications to real or simulated faults allows observing how applications respond to real-world disruptions.

Running chaos experiments used to be a complex task and required deploying very complex workloads. But with Chaos Studio it just became less complex, due to its availability from the Azure portal.

Source: Azure

What is Chaos Engineering?

Chaos engineering is a practice that helps teams measure, understand and improve their cloud applications by submitting those application to failures in controlled experiments. This practice helps identifying weak spots in your architecture, which if fixed, increases your service resilience.

Why Chaos Engineering?

The problem that Chaos Studio tries to solve is not new. Disaster recovery and business continuity are usually treated very seriously by organizations as outages can significantly impact reputations, revenues, and much more.

That said, practicing chaos engineering is a must for organizations actively working on business continuity and disaster recovery (BCDR) strategy. These drills ensure that applications can recover quickly and preserve critical data during failures.

Another important factor to consider is high availability (HA). Chaos Engineering helps validating application resilience against regional outages, network configuration errors, high load, and more.

Features

Some of the most interesting features provided by Azure Chaos Studio are:

• Test resilience against real-world incidents, like outages or high CPU utilization
• Reproduce incidents to better understand the failure.
• Ensure that post-incident repairs prevent the incident from recurring.
• Prepare for a major event or season with "game day" load, scale, performance, and resilience validation.
• Do business continuity and disaster recovery (BCDR) drills to ensure that your application can recover quickly and preserve critical data in a disaster.
• Run high availability (HA) drills to test application resilience against region outages, network configuration errors and high stress events.
• Develop application performance benchmarks.
• Plan capacity needs for production environments.
• Run stress tests or load tests.
• Ensure that services migrated from an on-premises or other cloud environment remain resilient to known failures.
• Build confidence in services built on cloud-native architectures.
• Validate that live site tooling, observability data, and on-call processes still work in unexpected conditions.

How to get started

Getting started with Azure Chaos Studio is simple, just log into your Azure Account and follow these steps.

References

• What is Azure Chaos Studio?
• Azure Chaos Studio

Next steps

• Create and run your first experiment
• Learn more about chaos engineering

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Adding Application Insights to your ASP.NET Core website
• Building and Hosting Docker images on GitHub with GitHub Actions
• Building and testing Node.js apps with Azure DevOps Pipelines
• Hosting Docker images on GitHub
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• How to build and run ASP.NET Core apps on Linux 
• 5 tools for Azure Development on Linux

Managed Grafana now available on Azure

It's now possible to run Grafana natively on Azure. Read to understand.

Source: Azure

Grafana, the most popular open-source analytics visualization tool is now available on Azure as a managed service. With it, customers can run Grafana natively within the Azure cloud platform without needing to provision or managing the backend services needed to run it.

Why use Grafana?

With Grafana, users can bring together logs, traces, metrics, and other disparate data from across an organization, regardless of where they are stored. With Azure Managed Grafana, the Grafana dashboards our customers are familiar with are now integrated seamlessly with the services and security of Azure.

Features

Azure Managed Grafana is a fully managed service for analytics and monitoring solutions. It's supported by Grafana Enterprise, which provides extensible data visualizations. Quickly and easily deploy Grafana dashboards with built-in high availability and control access with Azure security.

Source: Azure

Azure Managed Grafana also provides a rich set of built-in dashboards for various Azure Monitor features to help customers easily build new visualizations. For example, some features with built-in dashboards include Azure Monitor application insights, Azure Monitor container insights, Azure Monitor virtual machines insights, and Azure Monitor alerts.

How to get started

Getting started with Grafana on Azure is easy. Here are some links you should check:

• Go to the Azure Managed Grafana product page.
• Read the technical documentation.
• Share feedback on Microsoft Q&A.
• Join the Azure Observability Tech Community for detailed blogs and discussions.
• Read the Grafana integrations with Azure Monitor blog.

References

• Enhance your data visualizations with Azure Managed Grafana—now in preview

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Adding Application Insights to your ASP.NET Core website
• Building and Hosting Docker images on GitHub with GitHub Actions
• Building and testing Node.js apps with Azure DevOps Pipelines
• Hosting Docker images on GitHub
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• How to build and run ASP.NET Core apps on Linux 
• 5 tools for Azure Development on Linux

Build .NET apps on Google Cloud Functions

It's now possible to build serverless .NET apps on Google Cloud Functions

Source: Google Cloud Blog

Among the many benefits of  using .NET in Google Cloud is the ability to build and run .NET apps on a serverless platform like Google Cloud Functions. Since it's now possible to run .NET apps on Cloud Functions, let's understand how all of that works.

What is Cloud Functions?

Cloud Functions is Google Cloud’s Function-as-a-Service platform that allows developers to build serverless apps. Since serverless apps do not require a server to run, cloud functions are a great fit for serverless applications, mobile or IoT backends, real-time data processing systems, video, image and sentiment analysis and even things like chatbots, or virtual assistants.

FaaS

To develop your .NET apps so they're compatible with Cloud Functions, Google has made available this GitHub repo.  The Functions Framework lets you write lightweight functions that run in many different environments, including:

• Google Cloud Functions
• Your local development machine
• Cloud Run and Cloud Run on GKE
• Knative-based environments

Building your C# App

Assuming you're using .NET Core, the first thing you'll need is to build and run a deployable container on your local machine. For that, make sure that you have either Docker and the pack tool installed.

Next, build a container from your function using the Functions buildpacks:

pack build \
  --builder gcr.io/buildpacks/builder:v1 \
  --env GOOGLE_FUNCTION_SIGNATURE_TYPE=http \
  --env GOOGLE_FUNCTION_TARGET=HelloFunctions.Function \   my-first-function

Start the built container:

docker run --rm -p 8080:8080 my-first-function
# Output: Serving function...

Send a request to this function by navigating to localhost:8080. You should see Hello, Functions Framework.

Cloud Event Functions

After installing the same template package described above, use the gcf-event template:
mkdir HelloEvents cd HelloEvents dotnet new gcf-event

VB and F# support

The templates package also supports VB and F# projects. Just use -lang vb or -lang f# in the dotnet new command. For example, the HTTP function example above can be used with VB like this:
mkdir HelloFunctions

cd HelloFunctions
dotnet new gcf-http -lang vb

Running your function on serverless platforms

After you finished your project. you can use the Google Cloud SDK to deploy to Google Cloud Functions from the command line with the gcloud tool.

Once you have created and configured a Google Cloud project (as described in the Google Cloud Functions Quickstarts and installed the Google Cloud SDK, open a command line and navigate to the function directory. Use the gcloud functions deploy command to deploy the function.

For the quickstart HTTP function described above, you could run:

gcloud functions deploy hello-functions --runtime dotnet3 --trigger-http --entry-point HelloFunctions.Function

Note that other function types require different command line options. See the deployment documentation for more details.

Trying Cloud Functions for .NET

To get started with Cloud Functions for .NET, read the quickstart guide and learn how to write your first functions. You can even try it out with a Google Cloud Platform free trial.

References

• .NET FaaS Reference - GitHub
• Introducing .NET on Google Cloud Functions
• A tour of the .NET Functions Framework

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Get Started with the new Cloud Shell Editor 
• HTTP/gRPC server streaming available in Google Cloud Run
• .NET, Java and Ruby now available in Google Cloud Functions
• Eventrac, a new events functionality to build event-driven applications on the Google Cloud
• Docker and Apache Flink available in Dataproc’s Component Exchange
• Logs Buckets and Log Views now available in the Google Cloud Platform

Docker and Containers - Everything you should know

Much has been discussed about Docker, containers, virtualization, microservices and distributed applications. On this post let's recap the essential concepts and review related technologies.

Photo by chuttersnap on Unsplash

Much has been discussed about Docker, microservices, virtualization and containerized applications. So much, that most people probably didn't catch up. As the ecosystem matures and new technologies and standards come and go, the container ecosystem can be confusing at times. On this post we will recap the essential concepts and a solid reference for the future.

Virtualization

So let's start with a bit of history. More a less 20 years ago the industry saw a big growth in processing power, memory, storage and a significant decrease in hardware prices. Engineers realized that their applications weren't utilizing the resources effectively so they developed Virtual machines (VMs) and hypervisors to run multiple operating systems in parallel on the same server.

Source: Resellers Panel

A hypervisor is computer software, firmware or hardware that creates and runs virtual machines. The computer where the hypervisor runs is called the host, and the VM is called a guest.

The first container technologies

As virtualization grew, engineers realized that VMs were difficult to scale, hard to secure, utilized a lot of redundant resources and maxed out at a dozen per server. Those limitations led to the first containerization tools listed below.

• FreeBSD Jails: FreeBSD jails appeared in 2000 allowing the partitioning of a FreeBSD system into multiple subsystems. Jails was developed so that the same server could be sharded with multiple users without securely. 
• Google's lmctfy: Google also had their own container implementation called lmcty (Let Me Contain That For You). According to the project page, lmctfy used to be Google’s container stack which now seems to be moved to runc. 
• rkt: rkt was another container engine for Linux. rkt has ended and with CoreOS transitioning into Fedora CoreOS. Most of the efforts on that front should be happening into Podman now. 
• LXC: released on 2008, the Linux Containers project (LXC) is another container solution for Linux. LXC provides a CLI, tools, libraries and a reference specification that's followed by Docker, LXD, systemd-nspawn and Podman/Buildah. 
• Podman/Buildah: Podman and Buildah are also tools to create and manage containers. Podman provides an equivalent Docker CLI and improves on Docker by neither requiring a daemon (service) nor requiring root privileges. Podman's available by default on RH-based distros (RHEL, CentOS and Fedora). 
• LXD: LXD is another system container manager. Developed by Canonical, Ubuntu's parent company, it offers pre-made images for multiple Linux distributions and is built around a REST API. Clients, such as the command line tool provided with LXD itself then do everything through that REST API. 

Docker

Docker first appeared in 2008 as dotCloud and became open-source in 2013. Docker is by far the most used container implementation. According to Docker Inc., more than 3.5 million Docker applications have been deployed and over 37 billion containerized applications downloaded.

Docker grew so fast because it allowed developers to easily pull, run and share containers remotely on Docker Hub as simple as:

docker run -it nginx /bin/bash

Differences between containers and VMs

So what's the difference between containers and VMs? While each VM has to have their own kernel, applications, libraries and services, containers don't as they share some of the host's resources. VMs are also slower to build, provision, deploy and restore. Since containers also provide a way to run isolated services, are lightweight (some are only a few MBs), start fast and are easier to deploy and scale, containers became the standard today.

The image below shows a visual comparison between VMs and Containers:

Source: ZDNnet

Why Containers?

Here are guidelines that could help you decide if you should be using containers instead of VMs:

• containers share the operating system's kernel with other containers
• containers are designed to run one main process, VMs manage multiple sets of processes
• containers maximize the host's resource utilization 
• containers faster to run, download and start
• containers are easier to scale
• containers are more portable than VMs
• containers are usually more secure due to the reduced attack surface
• containers are easier to deploy 
• containers can be very lightweight (some are just a few MBs)

Containers are not only advantages. They also bring many technical challenges and will require you to not only rethink how your system is designed but also to use different tools. Look at the Ecosystem section below to understand.

Usage of Containers

And how much are containers being used? According to the a Cloud Native Computing Foundation survey, 84% of companies today use containers in production, a 15% increase from last year. Another good metric is provided by the Docker Index:

Open Collaboration

As the ecosystem stabilized, companies such as Amazon, Google, Microsoft and Red Hat collaborated on a shared format under Open Container Initiative (OCI). OCI was created from standards and technologies developed by Docker such as libcontainer. The standardization means that today you can run Docker and other LXC-based containers such as Podman on any OS.

The Cloud Native Computing Foundation (CNCF), part of the Linux Foundation is another significant entity in the area. CNF hosts many of the fastest-growing open source projects, including Kubernetes, Prometheus, and Envoy. CNCF's mission is to promote, monitor and hosts critical components of the global technology infrastructure.

The Technologies

Now let's dive into the technologies used by Docker (and OCI containers in general). The image below shows a detailed overview of the internals of a container. For clarity, we'll break the discussion in user and kernel space.

User space technologies

In usersland, Docker and other OCI containers utilize essentially these technologies:

• runc: runc is a CLI tool for spawning and running containers. runc is a fork of libcontainer, a library developed by Docker that was donated to the OCI and includes all modifications needed to make it run independently of Docker. 
• containerd: containerd is a project developed by Docker and donated to the CNCF that builds on top of runc adding features, such as image transfer, storage, execution, network and more.
• CRI: CRI is the containerd plugin for the Kubernetes Container Runtime Interface. With it, you could run Kubernetes using containerd as the container runtime. 
• Prometheus: Prometheus is an open-source systems monitoring and alerting toolkit. Prometheus is an independent project and member of the Cloud Native Computing Foundation.
• gRPC: gRPC is an open source remote procedure call system developed by Google. It uses HTTP/2 for transport, Protocol Buffers as the interface description language, and provides features such as authentication, bidirectional streaming and flow control, blocking or nonblocking bindings, and cancellation and timeouts.
• Go: yes, some of the tools are developed in C but Go shines in the area. Most of the open-source projects around containers use Go including: runc, runtime-tools, Docker CE, containerd, Kubernetes, libcontainer, Podman, Buildah, rkt, CoreDNS, LXD, Prometheus, CRI, etc. 

Kernel space technologies

In order to provide isolation, security and resource management, Docker relies on the following features from the Linux Kernel:

• Union Filesystem (or UnionFS, UFS): UnionFS is a filesystem that allows files and directories of separate file systems to be transparently overlaid, forming a single file system. Docker implements some of them including brtfs and zfs.
• Namespaces: Namespaces are a feature of the Linux kernel that partitions kernel resources so that one set of processes sees one set of resources while another set of processes sees a different set of resources. Specifically for Docker, PID, net, ipc, mnt and ufs are required.
• Cgroups: Cgroups allow you to allocate resources — such as CPU time, system memory, network bandwidth, or combinations of these resources — among groups of processes running on a system. 
• chroot:  chroot changes the apparent root directory for the current running process and its children. A program that is run in such a modified environment cannot name files outside the designated directory tree. 

Docker Overview

You probably installed Docker on your machine, pulled images and executed them. Three distinct tools participated on that operation: two local Docker tools and a remote container registry. On your local machine the two tools are:

• Docker client: this is the CLI tool you use to run your commands. The CLI is essentially a wrapper to interact with the daemon (service) via a REST API.
• Docker daemon (service): the daemon is a backend service that runs on your machine. The Docker daemon is the tool that performs most of the jobs such as downloading, running and creating resources on your machine.

The image below shows how the client and the daemon interact with each other:

Source: Docker Overview

Remote Registry

And what happens when you push your images to a container registry such as Docker Hub? The next image shows the relationship between client, dameon and the remote registry.

Source: Docker Overview

Images and Containers

Moving lower on the stack, it's time to take a quick look at Docker images. Internally, a Docker image can look like this:

Important concepts about images and containers that you should know:

• Images are built on layers, utilizing the the union file system.
• Images are readonly. Modifications made by the user are stored on a separate docker volume managed by the Docker daemon. They are removed as soon as you remove the container.
• Images are managed using  docker image <operation> <imageid>
• An instance of an image is called a container.
• Containers are managed with the  docker container <operation> <containerid>
• You can inspect details about your image with docker image inspect <imageid>
• Images can be created with docker commit, docker build or Dockerfiles
• Every image has to have a base image. scratch is the base empty image.
• Dockerfiles are templates to script images. Developed by Docker, they became the standard for the industry.
• The docker tool allows you to not only create and run images but also to create volumes, networks and much more.

For more information about how to build your images, check the official documentation.

Container Security

Due to the new practices of containers new security measures had to be applied. By default, containers are very reliable on some of the security measures of the host operating system kernel. Docker applies the principle of least privilege to provide isolation and reduce the attack surface. In essence, the best practices around container practice are:

• signing containers 
• only used images from trusted registries
• harden the host operating system
• enforce the principle of least privilege and do not elevate access to access devices
• offer centralized logging and monitoring
• run automated vulnerability scanning

The Ecosystem

Since this post is primarily about containers I'll defer the discussion of some the ecosystem for the future. However, it's important to list the main areas people working with containers, microservices and distributed applications should learn:

• Container Registries: remote registries that allow you to push and share your own images.
• Orchestration: orchestration tools deploy, manage and monitor your microservices.
• DNS and Service Discovery: with containers and microservices, you'll probably need DNS and service discovery so that your services can see and talk to each onther.
• Key-Value Stores: provide a reliable way to store data that needs to be accessed by a distributed system or cluster.
• Routing: routes the communication between microservices.
• Load Balancing: load balancing in a distributed system is a complex problem. Consider specific tooling for your app.
• Logging: microservices and distributed applications will require you to rethink your logging strategy so they're available on a central location.
• Communication Bus: your applications will need to communicate and using a Bus is the preferred way.
  
• Redundancy: necessary to guarantee that your system can sustain load and keep operating on crashes.
• Health Checking: consistent health checking is necessary to guarantee all services are operating.
• Self-healing: microservices will fail. Self-healing is the process of redeploying services when they crash.
• Deployments, CI, CD: redeploying microservices is different than the traditional deployment. You'll probably have to rethink your deployments, CI and CD.
• Monitoring: monitoring should be centralized for distributed applications.
• Alerting: it's a good practice to have alerting systems on events triggered from your system.
• Serverless: allows you to build and run applications and services without running the servers..
• FaaS - Functions as a service: allows you to develop, run, and manage application functionalities without maintaining the infrastructure.

Conclusion

On this post we reviewed the most important concepts about Docker containers, virtualization and the whole ecosystem. As you probably realized by the lenght of this post, the ecosystem around containers and microservices is huge - and keeps growing! We will cover in more detail much of the topic addressed here on future posts.

In the next posts, we will start divining in the details of some of these technologies.

References

• Docker - Get Started
• Docker - Overview
• OCI containers 
• What's a Linux container? | Red Hat 
• What is Docker and why is it so darn popular? 
• Here's how Microsoft is supporting the open-source Docker container model
• Kubernetes jumps in popularity | ZDNet
• Containers march into the mainstream
• Do you really need Kubernetes?
• Helping You and Your Development Team Build and Ship
• Top Six Open Source Tools for Monitoring Kubernetes and Docker
• Open Containers Initiative (OCI) - FAQ
• 2019 CCNF Survey 
• What's Envoy?
  
• containerd, with Derek McGowan
  

See Also

• Microservices in ASP.NET
• My journey to 1 million articles read
• Adding Application Insights to your ASP.NET Core website
• Configuration in .NET Core console applications
• Building and Hosting Docker images on GitHub with GitHub Actions
• Hosting Docker images on GitHub
• Send emails from ASP.NET Core websites using SendGrid and Azure
• Async Request/Response with MassTransit, RabbitMQ, Docker and .NET core
• How to build and run ASP.NET Core apps on Linux 
• 5 tools for Azure Development on Linux