APIs, Squads, and More: Your Guide to Life As a 360Learning Software Architect

On my business cards, my title says: Software Architect, 360Learning. Sounds cool, right? But what does it mean in reality? 

In our previous article, my fellow Software Architect Guillaume told you all about his first 100 days at 360Learning, offering an insight into how we do things around here – and some of the biggest surprises in store for new joiners.

In this article, I’m going to continue this tour of what it’s like to be a Software Architect at 360Learning by diving into my most important responsibilities and showing you how our team helps bring great learning support to our clients.

Of course, this is just a sneak peak of what is behind the scenes. But if you’ve ever wondered about joining our team, I’m here to give you an idea of what we’re working on at the moment, the “hot topics” for our fellow Software Architects, and what the future has in store for us!

Let’s get started with the basics.

API (Application programming interface)

You must have heard of APIs! They are everywhere, and most of them are designed as REST (REpresentational state transfer), meaning they are basically ways to communicate between components, by sending self-described messages and waiting for a response which gives insight on whether it worked as expected. API monitoring also ensures correct functionality.

One purpose of APIs is to hide the actual processes done to perform an action, exposing only the parameters required, and the result.

It’s our responsibility as developers and architects to make sure that:

• APIs visibility matches the need
• No unnecessary API is created
• No redundant API is created
• Only the minimum amount of parameters is needed (no superfluous parameters)

At 360Learning, our public API lets you automate several instructions related to users, groups, courses, and programs. By using our set of secured public functions, you can easily create connections between 360Learning and a third party software or a website.

In addition to this public API, the software architects team works at designing internal API as microservices, which helps ensure scalability along with asynchronous workers.

CI/CD (Continuous Integration / Continuous Deployment)

CI/CD pipelines are aiming at integrating changes in the existing codebase while ensuring that it does not break anything, and deploying this new code as soon as it’s ready, without waiting for a planned release.

When choosing the tools and steps within the CI/CD pipelines, you need to consider the following factors and constraints: 

• Type of architecture (monolithic, service-oriented).
• Kind of repository structure (mono-repository vs multi-repository).
• Budget allocated to these tools.
• Integration with version control system and infrastructure.

When properly defined, a CI/CD pipeline allows developers to push changes several times a day without waiting for a planned milestone.

At 360Learning, we are running a CI each time a development branch is about to be merged in the main branch. Features are released during milestones every three weeks to avoid changing the platform too often, which could be disturbing for users.

We are working on integrating a CD tooling to bring flexibility to this process and get to a point where each developer can release as soon as a change is ready. Having automated steps will allow us to go quicker.

Cloud

Cloud computing is often achieved using one of the three main cloud services providers - namely Amazon Web Services, Microsoft Azure and Google Cloud. They provide a bunch of services designed to match the vast majority of use-cases.

When using cloud services, you can easily customize the number of servers you’ll use, their memory and CPU, use either dedicated servers or go to serverless architecture. Resources can be shared by several customers, lowering the global maintenance costs when compared to on premise infrastructure while improving security and reliability.

At 360Learning, we moved our infrastructure earlier this year from our on-premise infrastructure to Microsoft Azure. Now we can scale more quickly and efficiently the servers we use or even move a bit further to serverless. 

Data

Data is core for every company, and architects have to structure it well. For example, well-designed databases help make everything go smoothly, but databases designed without thinking about future growth in data volume may lead to slow or even failing platforms and services.

Here’s what we consider when deciding our data storage options: 

• Do you need to store temporary key-values or counters? Then you may need an in-memory datastore (like Redis, Memcache).
• Do you need to store data you don’t need to access often and/or fast? Then a cold storage is a choice you may consider (like HDFS, DataLake).
• Do you need to store persistent and well-structured data, while accessing it fast? Then a hot storage is what you need (like MongoDB, SQL).

At 360Learning, our platform is historically built around MongoDB, where we store all of our data. This has led to some difficulties as the amount of data stored this way is growing quite fast.

That’s why  the architect squad is evaluating alternative solutions like Redis (to store temporary key/value data), and Snowflake (for Cold Storage). Introducing a data lake and a data warehouse will help us address our AI / BI / Dashboard use cases.

In fact, we’re so into data at 360Learning that we’re building a Data Team! More on that later.

Monolith vs Microservice Architecture

In a monolithic architecture, everything is in one place. This can from time to time lead to some ‘spaghetti plate’ architecture.

In a microservice architecture, each component is an independent piece of software with inputs and outputs clearly defined. The idea behind such an architecture is to provide ‘black box’ services doing their stuff without the other services knowing—or even needing to know—how it works.

Microservices have some important advantages:

• Improved elasticity
• Flexibility on technology choices (language, storage, hardware)
• Faster delivery
• Rolling update
• Resilience

The 360Learning code base has historically been a big monolith. This helped us quickly deliver features and adapt to our clients.

However, it has now reached a point where we need to cut it in pieces to keep this agility and performance. That’s why building independent services with a clearly defined scope will help us enforce modularity and ship faster.

You can expect more news about that in the upcoming year.

Referent

At 360Learning, each squad has its own referent architect; and each architect acts as a referent for several squads. What does it mean exactly? Developers in squads are working in a very specific part of the codebase, and may not need to interact with other squads except in some particular cases.

The referent architect helps to bring a more global vision in cooperation with other architects to make sure everything will work properly when interacting with other parts of the code. The referent architect is also here to help design complex features or data structures, to make sure it will behave as expected while the volume of data will grow.

Sometimes, a feature can look simple at first sight, but needs deeper analysis to check if the volume will not break the ability to load data, or to make sure it will still work when traffic starts to grow. That’s why our reference architects play such a key role.

Repository

When working on a codebase shared among developers, you need to choose how code is split—or not—and how everyone can work together without blocking each other. Basically, it’s about choosing either a monorepo (everything is in the same place) or multirepo (the codebase is split, e.g. in services, and each service is on its own repository).

There is no clear winning option here. While we’re using a monorepo for now, we are starting this conversation at 360Learning, especially in the context of moving from a monolith to microservices. It already sparked some fiery debates! More is coming soon.

Security

As for every company, security is key for 360Learning. It’s a key part of the role of architect to make sure features are securely designed regarding authentication and visibility as well as data integrity.

That’s why we take part in security audits requested by customers to bring a global 360Learning codebase vision. 360Learning has been recognized as one of the cybersecurity champions by Cyrating. Click here to learn more.

Squads

Teams, tribes, communities, chapters, guilds, squads: in every company, splitting developers—and other types of roles—is necessary to work efficiently on various projects. Each group works as a whole to deliver features.

At 360Learning, developers are dispatched among squads. Each squad focuses on a specific functional scope (e.g. Authoring, Dashboard, Stickiness).

Members of a squad are:

• A Product Manager
• A Product Designer
• An architect referent
• One or more developers

Software craftsmanship

Developers need to think about code quality—computational complexity, readability, maintainability—when they implement a feature.

Architects have a role to play here, as we tend to have more experience working with a range of different coding practices and technologies...It’s all about finding the right balance between a code easy to understand and maintain, and a very efficient code (sometimes, you just can’t have both).

Robert C. Martin’s Clean Code handbook is mandatory reading at 360Learning, and we can only encourage you to read this book!

TypeScript

Historically, our whole codebase was in Javascript. We decided to migrate to TypeScript in order to help keep the code clean.

Now a large part of the backend code is in TypeScript, and every new code is written using this language. Of course it adds some strong constraints—that’s the goal of a typed language—but it also helps increase robustness.

That’s all for now

By following along through these few topics, I hope you have now a taste of how Software Architects at 360Learning work together with developers, product managers and more generally every stakeholder.

From Micro-services to data management, these are just some examples of what we are working on in the 360Learning Software Architect squad. But there is more! I could have written a whole article just on Event-Driven architecture, or how we’re using AI and Machine Learning. There’s more to come soon on these topics, so stay tuned!

And if this tour of life as a Software Architect has piqued your interest in joining the team, great news: we are hiring! Feel free to get in touch with a member of the 360Learning team to find out more.