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.
Brian Schalme
Secure Your Micronaut App With FreshBooks
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: When to Use Them
Introduction
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.
Software Product Teams are Better Than Project Teams
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.
Become a Great Software Architect by Being a Great Communicator
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.
When to Use the The Layered Architecture Style
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.
Leadership Techniques for the Software Architect
Why is Leadership Important?
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.
Write More Maintainable Software With a Hexagonal Architecture
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.
What is a Hexagonal Architecture?
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?
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.
So What Is a Microservice?
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.
A Target or a Radar For Your Architecture?
Should you use a target architecture or an architecture radar for your organization? In this post I’ll explain what each one is. I’ll then highlight the differences between them. Finally, I’ll provide my opinion on which one is better and why I think so.
Many organizations, once they get to a certain size, see the need to decide on a particular technology stack. And rightfully so, because a proliferation of various competing technologies leads leads to an organisational drain. IT people need to become conversant and in most cases proficient at JBoss, WebSphere, and WebLogic if all three of these application servers are used. It means the organization ends up going “wide and shallow” across these three instead of “narrow and deep” on just one. In other words, they don’t develop a deep level of expertise on one application server, making problems harder to solve.
Note that this applies to programming languages, databases, application frameworks, and the key libraries an organization uses. It can also apply to server operating systems, routers and other network infrastructure, firewalls, etc.