Solace PubSub+
Published in

Solace PubSub+

San Jose O’Reilly Software Architecture Conference

I did attend the O’Reilly Software Architecture Conference at San Jose over three days and I will summarize the things I learned in this article.

Let’s start by summarizing the first conference : Continuous delivery in an ephemeral world.

In this conference I did learn about the CI/CD tools that AWS provides: CodeCommit, CodeBuild and CodePipeline. This conference was essentially a hands on tutorial on how to get going with a simple CI/CD project. All the steps are clearly outlined in this git repository : https://github.com/symphoniacloud/sacon-san-jose-2019-continuous-delivery.

First let’s talk about each of the AWS services involved here.

CodeCommit is a git based source code management system. It is free for up to 5 active users, up to 50 GB and 10k requests per months. Beyond that it will start costing money. There is nothing special about it except that it lives within the AWS ecosystem. The tutorial uses it for simplicity, however it also possible to have had used other git repositories such as Github.

CodeBuild is a managed build system. It compiles source code, takes care of running tests and creates packages for the software being built. This service is charged by the minutes, but the first 100 minutes per month is free. The minutes thereafter are charged at the rate of 0.005$ / minute.

CodePipeline is a managed Continuous Delivery system which automates the build, tests, and deployment of releases. It triggers when there are changes committed in the release’s branch. A pipeline defines a workflow made of multiple stages. Each state are made of a series of actions that allows implementing actions such as building, testing and deploying the release. CodePipeline integrates very well with the rest of AWS ecosystem. It allows to manage an infrastructure thru CloudFormation, thus taking away the pain of setting up all that is required to run a release. It also allows people to write their own custom plugins so that custom actions can be part of a pipeline as well. This makes CodePipeline flexible enough to work outside of the AWS infrastructure, at the cost of some extra development cost associated with the development and maintenance of those custom plugins.

The conference was about following the steps in the readme.md file of the repository mentioned above. I will not cover it as the file describes the process quite well. I recommend going thru those steps as it will not incur any costs, aside of the S3 bucket costs which might not be charged as it will be lower than a cent.

While this conference did showcase AWS technologies there are many other alternate possibilities when deciding on a CI/CD system. Here’s a few examples :

  1. Gitlab
  2. CircleCI

The conferences I attended thereafter were mostly about the role of a Software architect and skills that are important to the job. The conference “Thinking Architecturally” was a talk about the role of an Architect in the industry. This conference was given by Nathaniel Schutta (http://www.ntschutta.io/). Another notable conference covered the skill of using Visualization in communication. Since the other conferences covered the same subject during that event, I will just condense them all in this section.

The role of a Software Architect can be described in broad term as that of a Technology Lead. It boils down to guiding a technical team to choose the right tools to do the job as well as defining the system’s architecture. I will first talk about choosing the right tools, and then cover the architectural aspects.

Choosing the right tools is a very important aspect of the job of an Architect. The reality is that in the world of software development, new technologies, tools are released at an incredible pace. It is important to have some degree of awareness of what is available out there as well as what is coming up. The right tools can drastically speed up development and help the team only focus on the core business while tools takes care of the other aspects. An example of this would be to use a managed CI/CD system provided as a service. This would take away from the team the responsibility of developing and maintaining the CI/CD system. Another example is the choice of the right programming language. Depending on what is developed, using the right language will greatly affect team performance.

Also it is important to not lose focus by constantly seeking to be on the bleeding edge. For example, we do not need to adopt every new tools as they become available. This would be very wasteful as new technologies are initially immature as expensive to learn (As new technologies initially tend to change a lot, old technologies on the other hand tend to be very stable). So staying current is a matter of choosing the right trade off between stability and being current. It is important to remember that being on the bleeding edge is not necessarily a good thing. As one presenter said : “Remember, if you stay on the bleeding edge, be prepared to bleed! Because, no matter what, YOU WILL BE BLEEDING! And this is normal because bleeding edge also mean new, immature, in-flux, etc.”. In short, seeking to use new technologies and new tools can increased costs. Thus, in short architects need to be considerate and disciplined so that this does not become a quest of using the newest and coolest toys out there. Architects also have to instil discipline and educate the development teams on this matter. It helps to have a well defined process where people must explain why they want to use something new. Then the team as a whole will agree or not as to whether or not the new thing should be adopted or not. A single person should never just take something new and put it in (Unless it is a personal tool which won’t affect the development flow. Like an IDE for example). Also it is important to include new technologies responsibly and coordinate it when it can affect teamwork. For example, a team using SVN can’t just switch to GIT because one team member insist that SVN is old, and GIT is new, supports Pull Requests and it very popular now. Moving that team to GIT would require motives (What the team gain. Will that offset the costs of migrating, training people, getting used to it?). Also, this would need to be coordinated so the team will not stall during the transition to the newer SCM. All of this requires much more work than just learning GIT. It would require training people on GIT, explaining the rational to do the move. It might also involve process changes. Finally, it is always possible that an older technology might just suit the team better, and it is preferable to stick to it.

The other aspect of the Software Architecture job is to be responsible for the definition, evolution and maintenance of the overall system architecture. Developers tends to focus on a single part of the system at a time. Developers also need to focus on some areas to develop deep expertise. Architects on the other end need their focus applied at a higher level. Notably on system-level interactions, how the system components fits together as a whole. This perspective allows the Architect to be best suited at defining modules their interactions, and how to add functionality to them.

Finally, one aspect not to be overlooked at is communication. Architects needs to communicate their thoughts efficiently and accurately to a variety of audience. They need to work on the architecture with the developers and team leads. This type of communication will typically be very detailed and need to be very precise and accurate. Since architects are mostly developers themselves and very technical, this part is not too hard. The Architect doesn’t need to adjust the level of language much.

However Architects also needs to talk to business people, Managers to sell their ideas, or merely inform them about the software. This type of audience do not required the same level of details, neither are they interested in how a system work. They are instead interested in what the system do, and why is it done the way it is. They also need to know what changes are being made, and what business value those changes will bring. This requires a different kind of communication. As an example, business people won’t care that using GIT will make us more up to date, allows us to do Pull Requests, etc. Instead, what they want to know, is what will that bring to the company. So an architect would instead explain that GIT can enable developers to work differently, and deliver their changes faster. Thus reducing the latency of delivering bug fixes to a customer, or new features. Also saying that hiring will be made easier as there are more people familiar with GIT than the current SCM. This argument is very important for choosing a programming language also.

In terms of trends these two kept coming during the conferences:

  1. Service Mesh

Most people giving conferences were acknowledging the fact that Microservices can’t be ignored anymore. It is everywhere and many new projects gets designed that way. This is an example of a new disrupting trend reminiscent of past trends : J2EE, SOA, or even COM+ applications on Windows. Microservices are in fact a variation of SOA where the application will be modularized into micro services. A micro services is a single process that implements one aspect of the application’s functionality (IE. For example managing the application’s users could be handled by one micro services). Also microservices communication to each other typically with REST, although other approaches are also possible: asynchronous communication thru a message broker such as Solace PubSub+, RabbitMQ or Kafka. Most applications using other means that REST will typically use a mixture of REST and an asynchronous message bus.

These microservices tend to be loosely coupled to each other, meaning that it is not too hard to refactor the application by replacing microservices. It is also possible to update them individually. Because the development team is spread over smaller processes, CI/CD becomes much easier to realize than with a big monolith process.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store