Tag Archives: devops

What I find interesting in tech: DevOps and CI/CD (April 2022)

Yesterday I wrote about DevOps. One of the things I emphasized there was that DevOps was more than Continuous Integration (CI) and Continuous Delivery (CD). And while I still think that, I also know that for many people, CI/CD is a very important part of DevOps. It’s important for me too. Here’s a list of things I’ve found interesting in that area that I thought were worth sharing:

Generally:

Toolchains:

Tekton:

Helm

GitOps

On DevOps, or the important of a good reference architecture when doing IT Architecture

If you are designing an IT system, you can greatly benefit from a good reference architecture. A good reference architecture can be:

  • a superset of whatever architecture you design
  • a guide to what is possible in your design
  • a reminder of what is essential and what you may have left out
  • an explainer of all the potentially relevant parts to your design
  • a supporter of whatever architecture you do decide on
  • like a mentor providing you thought leadership and guidance on what works and why you need it

IBM has long put together such good reference architectures. Of all I have seen, this is one of the better ones I have seen: DevOps architecture: Reference diagram – IBM Cloud Architecture Center.


It covers all the stages of DevOps, from Planning to  Deployment to Learning. It shows the logical parts of the DevOps Architecture and what tools support that. It reveals the relationships between the parts, both static and dynamic. It reminds you of the things you need that you might not be aware of. I think it’s fantastic.

I think it is great for another reason. Implicit in the architecture is the definition —  at least for IBM and I — of what DevOps should be. It’s not just CI and CD. It’s not just a toolchain/pipeline from Dev to Ops. DevOps is really this entire cycle:

Each stage is important. Too often the focus is on Development and Deployment. But stages like Planning and Learning are an essential part of the DevOps cycle  that are essential not just for code quality but testing quality and ops quality.  It all ends up with better results for all the stakeholders of an IT system, from the business sponsors to the users.

Anyone involved with IT architecture, system design, IT testing, system operations or DevOps in general would benefit from studying that reference architecture.

(Images are links to IBM pages)

Tiny DOOM! And other things I find interesting in tech, February 2022


I’ve been doing work in a number of areas recently: IT architecture, Azure, Kubernetes and more. As I do that, I collect a number of links, which I have below. As well, I put together some Raspberrry Pi links, because I love my Pi. Also DOOM because I will always click on a DOOM link. Lots of good material. Let’s review!

IT architecture: I’ve been thinking much about IT architecture these days, and I’ve been writing about it here: BLM on IT. One thing that helped me think about it was this: 5 diagrams you need to document your solution architecture. This is also helpful: Editable architecture diagram resources: IBM IT Architect Assistant. In addition, something on DDD:  Apply Domain-Driven Design to microservices architecture.

Devices: These two pieces are on new trends in devices:  Dell envisions a sustainable laptop allowing you to replace parts creating a design you could grow old with and Lenovo ThinkBook Plus Gen 3 Laptop.

On the other hand, we have this: BlackBerry phone with keyboard is not dead. Remember netbooks? They were great little devices. Here’s a piece on them: Netbooks: The Form Factor Time Forgot.

Cool: Here’s something fun: The Best of 404PageFound and Other Primitive ’90s Websites That Still Exist. I love DOOM, so: Is this one of the smallest playable DOOM devices? and Pocket-Sized Doom Is Actually Playable. Speaking of small things, we have this, A VM in your browser,  this Writing a simple 16 bit VM in less than 125 lines of C and this System/360 simulator. Also this: CHUNGUS 2 – A very powerful 1Hz Minecraft CPU.

Raspberry Pi: for Pi fans, here’s some good links:

Cloud and DevOps: here’s some things I found worthwhile in that space

IBM: Here are two good initiatives my employer is providing: Good probono program from IBM to help environmental groups  and A good initiative from IBM to help on the matter of Racial Justice.

Azure: I have been doing tons of research of Microsoft’s Azure and so I have many links on it here. Enjoy!

Kubernetes:  I have been doing some Kubernetes work too which lead to these links in

Finally, here’s some other useful links I didn’t want to lose:

What I find interesting in tech, August 2021

Here’s a cornucopia of things I have found interesting in tech in the last month. As usual, lots of cloud, some Kubernetes, DevOps and software of course, as well as IOT. Grab a drink and read!

Cloud: 

Devops:

Software:

Kubernetes:

Security:

IOT:

Cool stuff:

General

(Photo by Sam Albury on Unsplash )

Quote

On specific Agile (software development) traps

There’s much positive to be said about the benefits of Agile software development, and the shift of software development teams is one sign that many feel this way.

However, I think there are some limits to Agile, and this leads teams to fall into certain traps over and over. Indeed, the Wikipedia page highlights a common criticism of Agile, namely:

Lack of overall product design
A goal of agile software development is to focus more on producing working software and less on documentation. This is in contrast to waterfall models where the process is often highly controlled and minor changes to the system require significant revision of supporting documentation. However, this does not justify completely doing without any analysis or design at all. Failure to pay attention to design can cause a team to proceed rapidly at first but then to have significant rework required as they attempt to scale up the system. One of the key features of agile software development is that it is iterative. When done correctly design emerges as the system is developed and commonalities and opportunities for re-use are discovered.

Now, it’s not the case that teams either do design or not. But I have seen that there are a number of specific traps bigger that Agile teams fall into that arise from lack of design. These traps arise from making tactical or limited decisions outside of a larger framework or structure, which isn’t surprising since Agile followers are guided by the principles that the “best architectures, requirements, and designs emerge from self-organizing teams” and “working software is the primary measure of progress”. Unfortunately what I’ve seen that lead to is:

  • Poor middleware/database system decisions: with this trap, you get teams making a decision on deploying a specific middleware package or database system that will support the software development they are doing. However, while that may be great for the Dev, it may not be great for the Ops. If you have enough teams making tactical decisions, you may end up with a more complex system than is necessary and greater technical debt that you want. Once you get enough data into your database systems, trying to reverse the decision may result not result not only in new development and testing, but a small (or not so small) migration project as well.
  • Poor infrastructure decisions: likewise, with this Agile trap I have seen teams using IaaS pick different images to deploy their software onto. Like the database problem, developers may choose one operating system (e.g. Windows) over another (e.g. Debian) because they are comfortable with the former, even if the production environment is more of the latter. The result can be your organization ending up with multiple VMs with many different operating systems to support and thereby increasing the operational costs of the system.
  • Poor application framework decisions: I see less of this one, although it can happen where teams pick an assortment of application frameworks to use in creating their software, and as with middleware and infrastructure, this will drive up the support effort down the road.

Given these traps, I think the way to avoid them is to inject some specific design phases into the overall software development lifecycle. One way to do that is to revisit a software development lifecycle (see diagram below) used by practitioners at IBM and documented in places like this IBM redbook. It has a waterfall quality about it, but it doesn’t have to be limited to waterfall type projects. It can be highly iterative.

The lifecycle process is shown here (taken from the redbook):

 

GSMethod

The part of the lifecycle in the large box is iterative and not all that different from an agile sprint.  But here you take time to explicitly make design / architecture decisions before building  software. You continue to iterate while making important design decisions before building.

Now, before you start your iterative software development lifecycle, you should need to  make specific architectural decisions. You should make these specific decisions in the solution outline and macro design phase. For smaller teams, these two phases may blend into one. But it is here in solution outline and macro design where you make decisions that are fundamental to the overall solution.

For example, in solution outline you could make overall architectural decisions about the application architecture, the choice of infrastructure technology, what application frameworks are the target for the team. These overall architectural decisions guide the dev, test and ops teams in the future. You may also decide to park some of these decisions in order to do further discovery.  Macro design could be next, where each of the dev teams make certain design decisions about their technology choices before they proceed with their iterations. As they are building and deploying code, they can run into issues where they need to make further design decisions, either due to problems that arise or technology choices that have to finally be made: and this is where the micro design phase is useful.  Micro design decisions could be quickly made, or they may require spikes and proof of concepts before proceeding. Or there could be no decisions to be made at all.  The main thing is more design checkpoints are built into the development lifecycle, which can result in less complexity, less maintainability costs, and less technical debt down the road. What you lose in velocity you can make up in overall lower TCO (total cost of ownership).

There is a risks to this type of approach as well. For example, if the project gets hung up with trying to make design decisions instead of gather requirements and making working software. The key stakeholders need to be aware of this and push on the design teams to prevent that from happening. If anything, it can help the key stakeholders better understand the risks before getting too far down the road in terms of developing software. Overall I think the risks are worth it if it helps you avoid these common agile traps.