Application deployments have usually meant deploying a new version of an artifact to Production, with stops along the way in Test, Staging, etc. All the new features and bug fixes become active when you deploy this new version. Although you’ve thoroughly tested the application with automated unit tests, functional tests, load tests, and performance tests, you’ve only reduced the risk of something going wrong in Production. If and when something does go wrong, you may need to rollback to the previous version. But what if the fix wasn’t as dramatic as a rollback? What if you could revert the one mis-behaving feature? Even better, what if you could select which features to activate? In this article I’ll explain how you can control your deployments with feature flags.
Suppose your client or your employer comes to you and says “We need you to help us understand how to set up a continuous delivery pipeline.” They assure you they are committed to the goals and benefits of Continuous Delivery, also known as Continuous Integration/Continuous Deployment (CI/CD):
- The software development teams want to reduce deployment risk.
- They like the idea of frequent small deployments during the workday instead of huge deployments once or twice a year.
- Teams no longer want to dedicate a full weekend to a massive deployment, with all the attendant stresses and risks that brings.
- The business is less tolerant of waiting months before they see even the smallest change; they want a faster time to market.
They have acquired all the tooling, and all they need is your guidance and leadership for how to set up a continuous delivery pipeline.
How would you approach this? What sequence of steps or phases would you use? In this article I’ll present some of my thoughts and suggestions.
History of Representational State Transfer
Roy Fielding coined the term Representational State Transfer (REST) in his 2000 doctoral thesis Architectural Styles and the Design of Network-based Software Architectures. In essence, he argues an API should use the existing HTTP verbs, and it should focus on representations of business objects rather than backend implementations. An example might be to model a Customer object the way the business knows and interacts with it rather than how it’s stored on the customer database table. In this post I’ll describe how to design an effective REST API using some of the concepts Fielding pioneered.
Most software development teams have one person with the role of Architect. Small teams of one or two people may not, but someone is thinking about architecture. This person’s title may be Solution Architect, Application Architect, Data Architect or Systems Architect. For now let’s consider all of them under the collective name of Software Architect. In this article I’ll talk about the characteristics of a good architect, and I’ll explain what a software architect does. I’ll also address the evolution of the role of software architect, and where it is today. By the end I hope you’ll have an answer to the question “so what does a software architect do anyway?”
What is it?
The pipeline architecture is one of the most common architecture styles used in designing software systems. Also known as pipes and filters, it consists of a series of discrete steps performed in a predictable sequence. This is different from the model-view-controller pattern in a layered architecture. In this article I’ll define what it is and when to use the pipeline architecture style.
So it’s time to move one of your legacy web applications from your on-premise data centre to a public cloud provider such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP). This may be a decision you made, or one that your leadership team made. In this post I’ll explain what you need to think about when figuring out how to migrate your web application to the cloud.
This post explains how you can secure your Micronaut app with FreshBooks. Using FreshBooks’ OAuth 2.0 implementation, I’ll show you how to use the Authorization Code grant to authenticate with FreshBooks.
FreshBooks is an invoice and accounting Software-as-a-Service (SaaS) for small business.
Microservices are all the rage these days. You’ve seen so many blog posts, technical articles, even job postings calling for microservices experience. So it must be the new way to architect applications, right?
Well, as with everything else in software architecture, it depends. It depends on the context you are dealing with. It depends whether the benefits of microservices outweigh their drawbacks for your situation.
In this post I’ll describe what microservices are, why they’re so good, and what their drawbacks are. I’ll finish off by giving you some guidelines to help you decide whether microservices are right for your situation.
When it comes to software development, product teams are better than project teams. I’ll explain why.
Seen This Before?
Have you noticed a pattern that most organizations use to build software? They assign a project manager to prepare the project charter that broadly defines the scope, cost and schedule. Senior management approves the charter, and then they assemble a team. Developers, analysts, QA testers join the new team even though they may be winding up other projects. Management assigns an architect. They might also assign a DBA, network and middleware experts on a part-time basis.
Software architects are responsible for the technical solution to ensure it achieves the desired business outcomes. To do so requires broad technical and business knowledge with a deeper understanding in a couple technical areas. It requires being able to see the big picture. It requires the wisdom to evaluate different solutions to the problem. But most of all it requires really good communication skills to convey the solution. You can become a great software architect by being a great communicator.