Skip to content
  • June 1, 2022
  • 4 mins read

Understanding cloud-native and SaaS architecture

Five years ago, when you spoke about cloud, the conversation would quickly turn to how difficult it was to solve security and login issues.

Microservices were not available, and cloud technology was mainly used for hosting purposes. That meant that, essentially, an organisation’s local network was just extended by spinning up a server in another location. In essence, cloud-hosted is no different from having an application running on-premise for scalability. 

Cloud-native, or software built in the cloud, is when true scalability becomes possible by utilising microservices. 


Understanding cloud-native architecture

Microservices are processes that only spin up when called upon and are limitless, contracting and expanding with a load. We can think of them as a series of services offered by the cloud provider that are grouped and communicated via well-defined, lightweight APIs. They are the building blocks of cloud-native software. Traditional monolithic architecture is, by contrast, a series of tightly coupled processes to run a single service. As more code is deployed, it becomes increasingly complex, inflexible and risky as more and more code interdependencies are created. 

Another advantage that cloud services offer is deploying quickly and easily, creating the infrastructure required for software development. Security is already in place and allows development teams to expand horizontally with services like the AWS Dynamo DB database function and build service layers with Lambda, much like Lego. It provides a common language and platform for developers. These microservices are loosely coupled together to make the broader product and can be deployed separately. The advantage here is that you can develop and test each area independently or in separate teams without impacting other services. In the case of Dina, the development team sits worldwide, which has been particularly important during the COVID-19 pandemic. Deployment and testing can happen anywhere and at any time without requiring technicians to all be in one building. During travel bans, the 7Mountains team has been able to remotely deliver several large-scale projects without a single engineer on-site in the client’s newsroom.

Cloud makes sense for story-centric because the software is available anywhere, and cloud-native makes sense because of the speed of deployment, the common language and the scalability with microservices starting and stopping as needed. 


The infrastructure is serverless, so no one central server runs the programme, thereby further reducing risk.

The other advantage of using microservices is that you pay only for what you use. When a service is at rest, it doesn’t incur a cost. The entire infrastructure lives in the cloud, which also means that the application does not depend on workstation computing power. The front-end client is very ‘thin’ in a cloud-native environment, and it requires very little computing power of its own, with the only requirement being a modern browser. With cloud-native, all computing is done in the backend and the personal computer becomes merely a display. 


The SaaS licence model

The SaaS (software as a service) or the licence model comes from the thin front end with code deployment in the cloud and cost alignment from the serverless environment. SaaS means that the same solution is running for every customer, particularly in a multi-tenant setup, so that each piece of code deployed is available to everyone. In the context of a newsroom, this means that customers benefit from each other's feature requests. New features are available instantly and seamlessly. The risk of updating a tool is significantly reduced with incremental and frequent releases, and code can easily be retracted from the tool if required.  

The SaaS model also allows customers to push much of the cost that was traditionally capital expenditure into ongoing operating expenditure because cloud-native services have fewer hardware requirements. This situation opens the door to startup streaming broadcasters who can spin up a fully functioning TV studio for a fraction of the upfront cost of a more traditional system. In the context of an established network, it means that new services can be spun up as quickly and easily as an entirely new build without touching the existing infrastructure. It means lower risks to the broader business for testing out the market with new offerings, as well as shorter turnaround times to get to air.

The principles of Story-centric workflows

This blog post is a chapter of the Ebook “The principles of Story-centric workflows” by the co-founder of story-centric newsroom tool Dina, Mads Grønbæk, and the Managing Director of Stem Media, Emily Dawson. To access the free ebook, go to the 7Mountains website here

FREE Ebook download

More from the Blog

November 23, 2023

Upgrades are stupid

Broadcast engineers, powerless to help, stand by staring at blue screens. The last update from IT is we’ll make it in...
April 5, 2023

Does it have to be open-heart surgery?

Just the thought of changing the newsroom computer system is enough to make TV executives break a sweat.
August 10, 2022

The importance of good design

“Design isn't just what it looks like and feels like — design is how it works.” - Steve Jobs If we think about how...

Sign up for our tech blog

Leave your email address with us to receive our next blog post. 

We are committed to your privacy and use the information you provide to us to contact you about our relevant content, products, and services. For more information see our Privacy Policy. You can unsubscribe from these communications at any time.

By clicking Sign up, you consent to allow Fonn Group to store and process the personal information submitted above to provide you the content requested.

We will never share your email address with third parties.