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.
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.
A layered architecture style is one where the presentation, business and persistence layers are bundled into one deployment unit. In this article I’ll discuss what it is, and point out the situations where you would choose to adopt it.
This is one of a series of articles where I am going to discuss each of these architecture styles: Layered, Microservices, Pipeline, Microkernel, Service-Based, Event-Driven, Space-Based, and Orchestration-Driven Service-Oriented Architecture (SOA). I’ll provide some insights based on my experiences, and I’ll mention some of the Java / JVM frameworks that support the style we’re talking about.
The typical path to becoming a software architect begins with years spent in the trenches of hands-on software development. You’ve accumulated technical knowledge that is broad and deep. Along the way you’ve developed your communications skills. And I don’t just mean status reports. I mean by mentoring junior developers, by giving presentations to your peers on the knowledge you have gained in a specific tool, framework or language, and by interacting with systems and business analysts.
Now that you’ve become an architect, more people will look to you as an authority, as an expert. Now you’re starting to provide guidance on software design and the usage of tools and frameworks. You notice you have more influence. You are now responsible for the technical solution of the product your team is building. You are now in a position of leadership.
Adopting the hexagonal architecture pattern produces software that is more maintainable. It enables you to respond to changes with less fuss than many other architectural patterns. In this article I’ll explain why and offer my thoughts on this pattern.
Alistair Cockburn first coined the term Hexagonal Architecture on his blog in 2005. Also known as the Ports and Adapters pattern, it is a layered architecture. It is a way of separating the domain concerns while making unit tests easier to write and changes simpler to accommodate.
Are microservices the same old SOA (Service Oriented Architecture)? Isn’t it just a rehash of the SOA hype? Let’s discuss the similarities and differences.
While microservices and Service Oriented Architecture (SOA) are two architecture patterns that deal with services, they have some differences. In fact, despite all the attention you see being given to microservices there are a couple use cases where SOA is the better choice.
A microservice a stand-alone process that communicates with its clients using a lightweight mechanism, usually HTTP. Its datastore is a database of some sort. The service is the only application that interacts with its datastore. So let’s say for example you have a CustomerService that reads from and writes to the CUSTOMER table and any related child tables. Only the CustomerService performs SQL actions on those tables; any other services that do something with Customer information must go through the CustomerService using its published interface.