How Atkins and Azure are helping reduce the carbon footprint of infrastructure development
Delivering design, project management and engineering consultancy services, Atkins is at the forefront of change when it comes to the future of infrastructure development.
We caught up with Matt Sanderson, Charlie Rogan and Dan O’Connor, members of the team working on Atkins’ DynamicObjects system, to learn about how they’re using Azure to reduce the carbon footprint for their clients and their infrastructure projects.
Sara: What is DynamicObjects?
Matt: We’re a design and engineering consultancy, and a portion of the work we do includes the design of assets that follow fairly strict design codes and standards. Designing such assets involves constantly looking up figures in design tables and referring to reference designs. This is not the most interesting work and probably not the most efficient use of our time. Because of this, Dan and a few others started thinking about how, if these projects are following particular rules, we could capture those rules and automate the design of these standard assets. So that’s what we did – we built a system called DynamicObjects, and it’s the second version of this that we’re moving to Azure. It also frees up our staff to concentrate on more creative engineering challenges which is why they wanted to be engineers in the first place!
Our legacy systems stored engineering rules in spreadsheets. This was well intentioned – we wanted people to create their own content, and when we built it a few years ago, there weren’t so many people in the company who knew how to code. A spreadsheet could capture all the algorithms and rules in a spreadsheet version so that all of our engineers would be able to join in.
Unfortunately, it didn’t work out this way! Creating a new asset was very complicated, and not only did it mean that new people didn’t join in, but it also meant that it was actually very difficult for the people who were creating assets in it because it made development more challenging. If you used a comma instead of a full stop, or had a stray capital letter or space, you could spend a whole day just trying to chase what happened and where the error occurred.
Our first version was supposed to have a no-code philosophy for the people creating the assets, but we realised that was a mistake and moved to a code version. By putting it on Azure and using Azure Functions, our users can call upon those functions to create their own assets, all in C#.
Charlie: Yeah, it’s an awful lot easier to capture the logic in C# than inside a spreadsheet. Ultimately people weren’t able to capture the logic if they weren’t capable of thinking like a coder, so we weren’t able to turn them into coders by giving them a simpler tool. All we were doing at that point was depriving the coders of a better tool.
Matt: Yep. So now that we’re in a .NET environment with tools like Intellisense, you can do development and debugging while receiving suggestions as you type. It’s one of those little things that makes development, not just the platform, so much faster.
A sewer overflow asset designed using the SewerOverflow Function App.
Sara: Why did you choose Azure?
Matt: Rather than spread ourselves thin across different cloud platforms, we decided to stick with the one, that way we could become more familiar with it and take advantage of any interconnectivity within the provider’s ecosystem. Atkins already has a strong relationship with Microsoft and its products, so we decided to go with Azure.
We had a previous version that was hosted with a private cloud hosting company, mostly providing infrastructure as a service. Our solution was fairly monolithic, so when somebody pointed out Azure Functions and the fact that you can write serverless code that you can put endpoints too, that became a big driver as well.
Sara: Can you give us some context around the project – what was the challenge you were facing and what did you build to address it?
Dan: Because our legacy system stored engineering rules in spreadsheets not in code, this made development and debugging extremely limited and extremely challenging, with negative knock-on effects on reliability and development time.
There were no proper cloud-based CAD solutions available at the time of development (2012), so our legacy system used desktop CAD software installed on dedicated “CAD servers”. We had separate user-facing “web servers” that received job requests and queued model builds to be processed one at a time on the next available CAD server. This was very slow and a massive bottleneck, which had the negative knock-on effect of the UX feeling un-interactive.
The stability of our desktop CAD software (Autodesk) was also a significant problem. Many builds suffered from geometry failures (such as ambiguous geometric results), which when added to everything else meant we had unscalable architecture. We were also spending significant maintenance time on our web servers (x3) as well as the CAD servers (x4).
A screenshot showing 7 Function Apps contributed by Civil Engineering staff, used for testing the new platform.
Sara: Why do you use Function Apps versus web apps?
Dan: Function Apps allow us to get some benefits typically associated with a microservices architecture versus the traditional monolithic web app – for example allowing us to maintain/upgrade a single Function App whilst everything else is unaffected.
Our DynamicObjects platform is comprised of a small set of Function Apps that provide the core platform services and a growing library of Function Apps uploaded by our mechanical and civil engineering community that encode the design logic for specific assets. For example we have an app for designing air-conditioning units and an app for designing sewerage overflow chambers. The DynamicObjects platform provides generic core services for auth, version control, assembling and delivering 3D content directly to a user’s CAD application and for providing a generic, dynamic user interface. This leaves our mechanical and civil engineers entirely free to focus on the bit they understand – the design logic specific to their asset. Azure Function Apps permits our community to write their asset logic in any of Python, JavaScript, .NET and more, and yet still integrate seamlessly with the core services of our Azure ecosystem which is written in C#.
We are using the function apps consumption plan. This suits us well because it means that as our community upload more and more apps to our platform, we do not have to be concerned about the cost of hosting them. If a Function App is perhaps only experimental or seldom used, then it will pick up a corresponding very-low monthly charge, if there’s any cost at all. Conversely, if an app proves very popular, it incurs a higher monthly charge. Azure monthly charges are itemised per Function App and allow us to easily identify and apportion charges back to our community fairly, so this cost model encourages our community to experiment, which is very important to us.
A screenshot of the Visual Studio Template Atkins provides that makes creating apps for the DynamicObjects platform simple.
Sara: What was the biggest thing you learned and why?
Charlie: I’d been coding for a while before coming to Microsoft Azure, but honestly the concept of there being different services in the cloud was something I didn’t know existed. There’s been a learning curve but it’s been good – not overwhelming. It’s been pretty eye-opening, and even outside of DynamicObjects we’ve been looking at their potential for other projects.
Matt: Absolutely. I think once you become aware of things like Function apps, it changes your mindset on how you can solve problems. It’s like you suddenly have a better toolbox which allows you to think differently about how you can solve things.
It’s also helped with our speed to market. Starting a new Azure Functions app can be done almost instantly, whereas previously, if you didn’t have the infrastructure to put it on, you’d be waiting quite a long time. In some cases, the infrastructure itself would have to be set up before you could even start to write a word of code.
Sara: What would you do differently if you did the project again?
Dan: Set up Azure Active Directory earlier! We implemented our own JWT token-based security but in hindsight we could have used the ready-rolled AAD.
Charlie: I went on a few learning courses as there’s so much available in Azure. We initially knew about function apps, but going on the courses made us aware of existing functionality, tools and services that we could just get off the shelf. Active Directory was was a good example of that, as well as Cosmos DB. Definitely do some of the Azure fundamentals courses early – they won’t make you an expert in any of those things, but they’ll make you aware of them and point you in the right direction.
An empty Visual Studio template sits ready for an asset developer to add the logic for their asset. All the scaffolding for interaction with the DynamicObjects platform is in one place.
Sara: Do you use DevOps practices? If so, how has that changed the way you work/what impact has it had?
Matt: Yeah, we use Azure DevOps Git repos. We use the Azure DevOps boards and run them through agile scrum methodology for development, which has proven to be very handy. All the information you need is in one place, so coordination, pipelines, code and so on can all be managed from one location.
Sara: Python’s important to you – why is that?
Dan: We have many graduate mechanical and civil engineers with Python coding experience. This is probably the most popular “hobbyist” language within our engineering community, with some 3100 members in our Python User Group.
Matt: .NET and Azure Functions apps work perfectly as mini apps as they can be written in many languages, including Python, and integrate seamlessly with the rest of the Azure ecosystem. At the moment we’re focused on the C# version, but there’s no reason why we couldn’t write tools so that people can develop apps in Python on the same platform as an app in C or JavaScript.
A second example of an applet for configuring a particular type of drainage asset.
Sara: How has the DynamicObjects project impacted the company from a sustainability perspective?
Dan: The DynamicObjects platform allows our mechanical and civil engineering community to consider and compare the carbon footprint of many more alternative solutions than they would traditionally have time and budget to consider. This means we are contributing to greener infrastructure, and since most of our civil infrastructure has a lifespan of 50 years or more, helping our project teams make more informed choices can end up making a significant contribution to society.
Matt: Traditionally, we’d have to win work by pricing competitively. This means that when you’re working on a design, you don’t have a lot of time and budget to present lots of different options. But when you start to automate designs like with DynamicObjects, you can produce a number of different options, which means we can bring things like carbon impact into the conversations we have with our clients.
We can also provide reports in the cart to weigh up different options for the client. There are different lenses you can look through, from CapEx and OpEx to carbon and health and safety; all sorts of factors. Certainly over the last year and a half carbon has become one of the main considerations behind how we’re designing things.
Sara: What’s next for DynamicObjects?
Matt: We’re currently looking at client plug-ins to support other CAD apps like Autodesk Revit. This new version of DynamicObjects will be accessed through a plug-in to a CAD application called Civil 3D, which is an Autodesk product, but there are other CAD applications that we want to be able to access it through.
