Posted on

Application Architecture Design Principles

This is an article from DZone's 2023 Software Integration Trend Report.

For more:


Read the Report

Designing an application architecture is never complete. Regularly, all decisions and components need to be reviewed, validated, and possibly updated. Stakeholders require that complex applications be delivered more quickly. It's a challenge for even the most senior technologists. A strategy is required, and it needs to be nimble. Strategy combines processes, which aid in keeping a team focused, and principles and patterns, which provide best practices for implementation. Regardless, it's a daunting task requiring organizational commitment.

Posted on

Architectural Patterns for Microservices With Kubernetes

This is an article from DZone's 2022 Kubernetes in the Enterprise Trend Report.

For more:


Read the Report

For some time, microservices have drawn interest across the architecture and software engineering landscape, and now, applications comprised of microservices have become commonplace. So what exactly is the definition of a microservice? That is somewhat of a loaded question as there is plenty of debate on granularity, segmentation, and what designates a microservice. For the purposes of this discussion, a microservices-based architecture is segmenting an application's units of work into discrete, interoperable components. This is a broad definition, but it is workable in that it identifies two foundational microservice concepts: discrete and interoperable. 

Posted on

Jump Into the DevOps Pool. The Water is Fine.

In scanning the IT landscape, the call for DevOps engineers remains toward the top of many companies’ priorities. A nationwide search through various job posting sites returns literally thousands of DevOps opportunities. However, reviewing these job postings shows that the skillsets required are widely varied. In comparison, software development job descriptions and requirements tend to have a narrower focus – broadly speaking, a language and a particular framework. DevOps job descriptions and requirements range from implementing continuous integration and continuous delivery (CI/CD) processes, to building infrastructure, to configuration management, to cloud operations, to writing code in any number of languages, and so on. It’s an impressive and intimidating list. Have you considered joining the DevOps wave but have been challenged in getting a clear picture of what DevOps is or means? If so, you’re not alone.

What is DevOps?

While many organizations have DevOps teams, even within a single organization, there are likely to be multiple roles within a DevOps team. Why is that? The reason is that DevOps is a process, and various roles within a DevOps team each contribute to the process. The DevOps process is a product of the evolution of Agile development processes. With Agile, production-quality software is iteratively delivered, which drives the need to deploy software more often. The process of getting software into production needed to be streamlined, thus the DevOps movement and process was born.

Posted on

Kubernetes Package Management With Helm

This is an article from DZone's 2021 Kubernetes and the Enterprise Trend Report.

For more:


Read the Report

Introducing Helm

Helm is a package manager for Kubernetes. Given a running Kubernetes cluster of any type, Helm is used to manage the deployment lifecycle of just about any type of Kubernetes resource, including the management of many Kubernetes runtime components. A very common analogy used in describing Helm is that Helm is to Kubernetes as apt is to Debian-based systems and yum or rpm is to Red Hat-based systems. Beyond package management, many aspects of configuration management are also built into Helm. Helm was initially developed by a company named Deis, which was acquired by Microsoft. Microsoft fully supported and accelerated the development of Helm, and it is now a part of the Cloud Native Computing Foundation (CNCF). 

Posted on

The Anatomy of a Microservice, One Service, Multiple Servers

The first article of this series, "Microservice Definition and Architecture", includes a high-level architecture diagram. Subsequent articles have covered the architecture’s first two layers. It’s (finally) time to look at the API Server layer and expose the business service to the outside world. As has been the case for this series, I’ll continue to demonstrate the solution through a sample project that can be found on GitHub at https://github.com/relenteny/microservice.

There are two API Servers; RESTful and gRPC. The source is located in the media-server module. Why two implementations? The transport mechanism does make a difference. By far, the most common protocol is REST. The protocol is easy to produce and consume. It leverages a very mature transport mechanism; HTTP 1.x. Its ubiquitous support across tech stacks really makes it the API Server de facto standard protocol.

Posted on

The Anatomy of a Microservice, Defining the Domain

Find out what's going on inside your Microservices.

Part 1 of this series, Microservice Definition and Architecture, I provided an overview and some guidelines for consideration when building and deploying microservices. As we work our way to microservice deployment, we’ll begin with a review of microservice development principles and patterns. As mentioned in Part 1 of this series, the project is written in Java using the Quarkus framework and is available GitHub at https://github.com/relenteny/microservice.

You may also like: Microservice Definition and Architecture

Posted on

Microservice Definition and Architecture

Hmmm...what are microservices?

Deploying Microservices

You may be asking yourself, “Why another series of articles on microservice?” Yes. Microservices are a popular topic. Yes. Containerization has pushed the microservice discussion even more to the forefront. Why another series? It’s certainly not the case that other articles, blogs, books, etc. are not good. Most are very good. Then, why another series?

You may also like: Microservices: Are They For Me?

Posted on

Planning and Designing Your Docker Image Hierarchy

Design Docker images with a heirarchy in mind.

Over the past few years, I’ve had the need to create Docker images for various applications/microservices. In my case, the most predominant use cases were Java and Python. Of course, there are a myriad of Java and Python images available on Docker Hub, and often these images can be used as a good basis for applications. However, as time goes on, I found myself having to manage multiple applications requiring different versions of these platforms.

It’s easy enough to reuse and customize a base image, but it tends to lead to repetitive work in configuration. Over time, like many open source projects, Docker Hub images evolve. That is to be expected. However, challenges arise when that change breaks the way dependent images are assembled or required versions aren’t available. In addition, I have also worked in environments where regulatory considerations were a priority and pulling images from Docker Hub tended to generate questions regarding the source and assurances of meeting specified guidelines. Anyone whose been involved in compliance and security audits understands that the use of external resources always requires some type of additional validation demonstrating the authenticity of the source. It can be done, but, with audits, the fewer questions raised are and the more straightforward the process.

Posted on

Deployment Matters

Is there something missing from the SDLC?


Why is software developed? There are many answers to that question. Just about any way you look at it, software is developed to serve a purpose. It might be an aid in business productivity, perform repetitive tasks, automate complex processes, for entertainment, or even improve the productivity of those writing software. Software may be written by engineers within an organization in support of the organization’s business objectives. Software is also written by vendors to be either sold as a product or offered as a service. It’s apparent that the reasons and purposes for developing software are vast.

Posted on

Why I Returned to Windows

https://youtu.be/7aLsjhPzCAI

I’m a Unix guy. Note that I did not say Linux. When I started my career, many small to mid-sized companies were running on minicomputers from companies such as IBM, Digital Equipment Corporation (DEC), PR1ME Computer, and others. Dr. Who fans might get a chuckle out of this blast from the past.