Multiple Account Strategy, Cross-Account IAM Roles, and Role Switching – Part two of this three part series.

In the second installment of our multi-part post on using multiple AWS accounts in your organization we’re going deeper into the technical side of creating cross-account roles for IAM authentication. In this post we’ll discuss Trusted Entities, IAM permission granularity, step-by-step directions to create a custom IAM role and role switching using the custom URL for the new role.

IAM roles can be used in several different ways:

  1. Assigned to services like lambda, or to ec2 instances to allow permission to the instance without passing credentials
  2. Assigned to user accounts to control what a user has access to
  3. Allow access from other AWS accounts using Trusted Access
  4. Control S3 access
  5. And even more!

In this blog post we’ll be concerned primarily with points 2 and 3. We’re going to create an IAM role with specific privileges and allow another account to assume that role. Whether that account belongs to another organization (MSP, Consultant, etc.) or to another group within your own organization (Developers, DevOps, or even Finance and BizOps), the method for creating the role is the same.

The first thing we’ll need to determine is the account number for the role you want to grant privileges to.  That can be done in several ways – often it’s in the account sign-in URL {https://{your_account_number_or_alias}}, though in some cases your organization may be set up with an Account Alias which would then take the part of the account number in your sign-in URL. If your organization is set up with an alias, you can find the AWS Account ID in the lower left-hand corner of the IAM (Identity and Access Management) services page. 

Take note of this ID, as we’ll need it in later steps. This
is the ID that we’re going to set as a Trusted Entity for the IAM role we’ll
create. What is a Trusted Entity? A Trusted Entity is an object from outside of your AWS Account which is
allowed to gain access to a resource within your account – in our case that
resource will be an IAM role, which will in turn grant them permissions within
the account.

Depending on the duties of the user(s) you’ll be granting
access to, you may want to have multiple IAM roles with specific and granular
access configured for each. The first step in creating a new IAM Role is to
select what type of trusted entity will be using the role – either an AWS
Service, Another AWS Account, a Web Identity, or SAML federation.

We’re going to select “Another AWS Account” and
enter the account ID we noted earlier. If the API or CLI are all that will be
used, you can select “Require external ID” – however, if you
anticipate this being used via the web console you will not select this option.
You may also choose to select “Require MFA” for additional security.

This will require that the user switching roles be logged in
to their console session with an MFA device. Next, we’ll attach permissions
policies. If you’d like to use custom permissions you may create a new policy,
or if you want to use default policies you can select them. Let’s walk through
creating a custom policy.

IAM permissions can be configured either via guided GUI or
by manually entering JSON. 

Let’s assume you’ve got a developer who needs access to
trigger any Lambda function on the account, but should not have access to
delete or create new functions. You may also want to allow them to update the
function’s code. The below JSON is a simple example of a policy which would
allow a user to list functions and tags, invoke functions, and update the code
for all functions on the account.

        "Version": "2012-10-17",
        "Statement": [
            "Sid": "DeveloperLambdaFunction",
            "Action": [
            "Effect": "Allow",
            "Resource": "*"

This would still require someone like a DevOps Engineer, Project Owner, etc. to create new lambda functions. Alternatively, you could require that all functions be created and updated via CI/CD and remove the “lambda:UpdateFunctionCode” tag from the permissions, but that is outside the scope of this post. Click Review Policy, add a meaningful Name and Description and click Create Policy. Remember, you can assign up to 10 policies to a role.

Back in the Create Role window, you should be able to search
for your newly created role after refreshing the window.

Select your role, and click Next: Tags. Add any tags you may want to use  – remember, tags are great for billing, logging and monitoring, among many other reasons. When you’ve added your tags, click Next: Review. Add a meaningful Role Name and Description and click Create Role.

After creating the role you will be returned to the list of
all roles on your account. Click on the new role we just created, and you’ll be
taken to the Role Summary page. On this screen you’ll find the URL which can be
used to automatically switch roles.

When a user who is signed into the remote account clicks this link they will be taken to the Switch Role page, with the account and role pre-populated. Select whichever color you would prefer from the provided palette, enter a meaningful Display Name if you choose to, and click Switch Role.

That’s it! You’ve created a cross-account IAM policy and signed in from a remote account! Stay tuned for part 3, where we’ll discuss Master Billing accounts, tagging, and billing reports!

Take another peek at Part 1 >

How to Manage an Effective Digital Transformation in Changing Times

Tech leaders are facing new challenges in 2022: more pressure than ever to keep systems thriving in the midst of huge technical demand… and the threat of losing the skilled labor required to do it. In this exclusive series, we’ll share some key takeaways to help tech teams stay agile:

  • Why digital transformation is an insurance policy against attrition and change
  • How to identify and manage the technical debt that threatens employee productivity and fulfillment
  • How DevOps practices can liberate and improve tech teams
  • The playbook we use ourselves at MercuryWorks to create painless digital transformations for our enterprise clients
strategy planning for a custom application

Progressive Web Apps are just websites that took all the right vitamins.

Progressive Web Apps (PWAs) are websites that use modern web technologies to deliver experiences closer to those delivered by native iOS and Android apps.  They combine the last decade’s browser and web construction advances (responsive web designJavaScript enginesservice workers and web storage) to create a whole greater than the sum of their parts—a capable substitute to native applications.

In this article, we’ll dive into some of the common technical questions we get around PWAs, including how they work, when they’re a good option, and how to build a solid PWA strategy. 

How Does a PWA Work?

At its core a PWA is a website that can be installed on your device (phone, tablet, PC or Mac), app icon/shortcut and all. A PWA will pull updates in the background each time a user runs it.  As you update your web application, not only will visitors to the app site gain access to new features, but so will PWA users—all without explicitly performing any kind of update.

When a user interacts with the PWA, the PWA can check the capabilities of their device and load more data in the background. This opens up scenarios of preparation for coming interactions, resulting in the appearance of a more capable application. PWAs can also offer app-like increased functionality traditionally unavailable to websites, such as offline usage, notifications when new data is available, and various other conveniences. This progressive unfurling of functionality based on the user’s device works on the same code base and in parallel with users of your website in a browser.

Why a Progressive Web Application?

User experience research shows that while users turn to native apps because they provide a cleaner and smoother experience (as compared to websites), mobile websites are their first port of call for exploring a topic and for seeking specific information when on the go.  While certain modern app features like ability to work offline and subscribe to notifications have not traditionally been present for websites, their findability via search engines contributes to their preferences for information retrieval.

One factor driving the affinity for native apps by mobile users is that native apps are de facto created mobile-first from the start.  While “mobile-first” has been a design mentality for websites in many circles for a few years, it is not universally practiced.  Thus we arrived at the “there’s an app for that” reality: native apps delivered what mobile websites couldn’t – the ability to work offline and an experience optimized to the mobile form factor.

On the pro-web end of things, we encounter the inherent friction of native app distribution to end users.  While distributing software to end users via a centralized app store is convenient for developers, it imposes work on users.  Store providers impose a review period on new releases, users can be running any of your past versions (tech support goes way up there) and in the worst case the app store may even reject an app entirely.  Finally we encounter friction on the part of creators for both initial development and updates for several versions of native apps for different operating systems and form factors.

From the dawn of the web, this process has been greatly simplified: instead of downloading and installing, you typed in a URL or clicked on a link.  When you had a new version of your app, new content or altered layout you published your website and your users got it right away (and only one version ran at a time!).  This was the vision of proper software-on-demand that in some ways the advent of native apps regressed on.

Thus the industry came together (Apple begrudgingly so) to find a way to marry the immediacy and low entry barrier of the web with the form and functionality of native apps.  The “why” of PWAs became:

  • To provide a user experience on par with native mobile applications

  • To increase speed and cost of development as compared to by-device native development

  • Provide connectivity flexibility: work offline or on low-quality networks

  • Eliminate app installation friction, avoid app stores’ “walled garden”

  • Eliminate version release and support headaches

  • Create re-use across desktop, phone, tablet and other form factors

  • Improve upon typical website re-engagement

  • Provide more timely user information with service workers and new web APIs like the Web Push and Notifications APIs

What makes for a good PWA?

In my experience, native apps have less features than the same company’s website/web app but carry them out extraordinarily effectively: they’re very streamlined and tailored towards the user’s “job to be done“.  Also, it’s there on prime real estate: the user’s phone screen.  To be competitive to this experience and meet user’s conditioned expectations, a PWA needs to be:

  • Discoverable – a PWA is available on the web as well as in app stores
  • Installable – the PWA displays alongside all the other apps (start menu, icon on homescreen)
  • Responsive – an interface catered to the environment, offering smooth and immediate interaction
  • Network independent – functions both offline, online and on flaky connections
  • Fresh – updates happen automatically with no concerted installation process
  • Safe – data delivered over secure channels
  • Linkable – accessed via a simple delivery mechanism, such as a link (including deep links into specific sections of the app)

When it comes to PWA construction, “FIRE” is a convenient acronym to keep in mind:

  • Fast
    The first contact with a PWA interface is an immediate, responsive and enjoyable experience
  • Installable
    The PWA installs like any other native app, showing on your desktop or homescreen rather than requiring a browser
  • Reliable
    The PWA is available and responsive every time the user opens it, on par with any other piece of installed software
  • Engaging
    The PWA follows the best practices for high-quality UX and works irrespective of network state or device capability – there is never an empty screen telling the user to go online or upgrade

Interested in Progressive Web Applications?

Let’s Talk

Are PWAs supported?

Many of the piece-parts that make PWAs possible have been in existence and enjoyed some amount of browser support for years, especially from Google Chrome.  Certain key browser supports to make them a viable wide-band solution to rival native apps.  Apple’s Safari browser’s notable lack of support for Service Workers and Web App Manifests effectively put the iPhone and iPad ecosystem out of reach for a PWA.  Thus for years prior to 2018, the PWA was nullified as a viable alternative to developing platform-targeted iOS and Android apps.

Thankfully, that is behind us and now, for the vast majority of users, PWAs are a highly viable and supported option: all told, as of April 2022 PWAs are supported for about 95% of worldwide users.  The following details break down the browsers and OS versions that, as of August 2020, fully support PWAs:

  • Windows
    • Edge 17 (legacy Edge)
    • Edge 83+ (Chromium Edge)
  • MacOS
    • Safari 11.1+
  • Both Windows & MacOS
    • Chrome 45+
    • Firefox 44+
  • iOS
    • Safari 11.3+
  • Android 5+ (Lollipop)
    • Android Chrome
    • Samsung Browser

For IE11 and other ancient browsers (even Microsoft is abandoning IE11) the PWA will work in a typical website fashion - only PWA features of offline support and web notifications will not work. That is a failure mode I can live with.

What makes for a solid PWA strategy?

First the good news: the first step in any PWA strategy is to build a modern website that follows a host of best practices:

  • Responsive web design principles (ensure high fidelity layout for mobile, tablet and desktop)
  • Highly performant (you want the first experience to be fast and smooth)
  • Be as small as possible (eventually this will be installed on a user’s device)
  • A high level of accessibility (Google Lighthouse is a good tool to gauge 508 compliance and overall performance)

A key mental framing to keep in mind is that for likely the first time in your team’s careers, their users will be using installed software outside the confines of a browser. The moment you remove a browser’s UI (and attendant UX features), users will assume a superior level of functionality, so be ready to not only deliver on that expectation but also avoid the crutches a browser’s chrome provides for you. A key side effect of how a PWA works is that there are no back buttons, refresh button and other niceties that browsers provide.

Here are few fundamental considerations for a PWA that diverge a bit from a typical “best practices” web application:

  • Think About UI Two Ways
    Mock screens with and without the browser UI to help uncover any potential layout issues.  And remember that some users will be using your PWA as a web app in a browser (not all users will be using it in installed mode).
  • Plan for Different Connectivity States
    Remember to design for different connectivity states: online, offline, flaky network, content loading and content failing to load.  One of the more complex design patterns is sync’ing state and content after loss of network connectivity.
  • App Icon and Start Screens
    Not only should the app icon and starting state screen be attractive and on-brand but also consider each different OS and provide an icon for each (nope, they aren’t all the same size and shape).
  • Asking Installation Permission
    Think about when you will want your app to prompt the user to add the PWA to their home screen/desktop.  Asking too soon is definitely pushy and bound to failure but asking too late and they might not bother.  My general advice is to wait until the user has done enough in the app to be bought in but not so long that they’ve just bookmarked it.
  • Asking for location data
    Don’t just ask for permission to access the user’s location as soon as they open the app – wait to ask for permission until their is a purpose-contextual reason to ask for this level of information and provide value for doing so.

Finally, before going overboard with every feature now possible with a PWA, decide what “jobs to be done” a user is looking to accomplish.  A well-designed PWA (and any digital product) should make it easier for users to complete their goals.  Some framing considerations:

  • Have a clear and memorable value proposition in a prominent position – make sure the user knows what they can do
  • Make procedures as smooth as possible; users tend to have little patience completing forms and finalizing the checkout process, particularly on phones and tablets
  • Be careful with push notifications – they can increase engagement but carry more impact if delivered at the right time (in other words, not as soon as they hit your home page)

Let’s talk about Progressive Web Apps

Let’s Talk

Some fine points

There are a few fine points mentioning before I show you some highly successful PWAs.  The following are tactical points to be aware of as you start your PWA journey:

PWA Branding and Device Icon
  • Add To Home Screen
    • Android Chrome will prompt the user to add the web app to their home screen
    • iOS Safari doesn’t prompt, but we can add our own prompt
  • Branding
    • We add client-branded images for app icons and the loading/splash screen to give the app a native feel (Android has more options, iOS is more limited)
PWAs and Push Notifications
  • Web notifications are only operable while the user is online
  • We can send web notifications to users on supported desktop browsers
  • PWAs can send native push notifications to Android devices with the PWA installed as an app
  • PWAs cannot send native push notifications to iOS devices or while the app is not being used
    • To overcome the iOS limitation, we can send our own designed notifications while they are using the app
    • Finally, as a full solution option, we can create our own notification service using Web Sockets or a service like Google Firebase
PWA Offline Use Considerations

Questions that need to be answered answered before implementing a PWA:

  • Do we need to store any data offline?
    • If users are primarily searching, we may not want to store data offline
    • Data looks to change often, if not daily, so keeping data current is a concern
  • Do users have good WiFi or LTE connections?
  • How will the app work with authentication and security/logging in?

Resources around offline support (provided this is a key feature for your app):

    • Navigator.oneLine API
      • Built-in browser support for detecting of a user is online or offline
    • Local Forage
      • Helper library for browser compatibility for storing data offline in browsers best supported database
    • Workbox
      • Google-backed JavaScript libraries for adding offline support to web apps
PWAs aren’t just for smartphones

The vast majority of literature and general coverage about PWAs concerns their use on smartphones.  A key point to keep in mind is that PWAs are also extremely powerful on the desktop as installable software for your users—the cross-platform benefit is key to how a PWA works. While having an app icon on your users’ smartphone is extremely powerful, so is having a shortcut in their Mac or Windows taskbar!


While the possibilities of PWAs are still new, several leading organizations have begun to innovate and notch some highly successful outcomes.  The following are three major PWA accomplishments that have hit my radar:

BMW uses a PWA to provide better user experience
  • 3-4x faster load times
  • 50% increase in mobile users
  • 4x increase in conversion rate to sales site
Lancome PWA app development
  • 84% decrease in load time
  • 17% increase in conversions
  • PWA mobile traffic now greater than desktop
Trivago used a PWA to increase sessions by 50%
  • 50% increase in mobile sessions
  • 150% greater engagement from PWA installers
  • Covers 55 countries

Will a PWA work for your organization? 

If you’re still operating under the weight of a monolithic legacy system, a PWA can provide a way to enable new functionality as part of an incremental strategy. For example, Mercury client Gulf Winds was able to implement a PWA to enable quick wins and integrate with their existing system. While a more robust digital transformation is still on the roadmap, we were able to serve Gulf Winds’ most pressing needs and drive immediate results in part with the “low-hanging fruit” of a progressive web application.


Interested in Learning More?

Fill out the form below and our team will follow up shortly.

"*" indicates required fields

For years, developers have traditionally operated their sites within large, monolithic content management systems (CMS) like WordPress. 

There’s a reason why WordPress remains the dominant CMS worldwide, powering an outsized proportion of the world’s websites. It allows anyone—even those with little to no coding knowledge—to create high-quality websites. With just a few clicks, users can create and manage pages and posts and host images, videos, and more digital content to be displayed on the web based on a preset theme or layout.

For developers, a traditional CMS like WordPress is powerful because it provides access to an admin environment to manage content, but the front-end experience can be lacking and oftentimes bloated. Wouldn’t it be great if there was a solution that combined the well maintained and developed admin interface of WordPress with the freedom of a complex front-end experience that web applications have today?

This is where a headless CMS approach comes into play. In this article, we’ll discuss the headless CMS vs. traditional CMS approach, and how headless WordPress is actually poised to offer developers the best of both worlds.

Headless CMS vs. traditional CMS architecture

In a traditional, monolithic CMS approach, the website content and front end are both stored within the same WordPress architecture. While this is convenient for users without development knowledge, it requires developers to use the languages and frameworks that WordPress defines: PHP, CSS, and JavaScript.

But with a headless WordPress approach, developers can use WordPress admin interfaces and content management without having to rely on WordPress’s bloated front-end design. You can hook into WordPress’s RESTful API endpoints from any application to develop rich web applications with ease. This allows users to leverage newer and popular web frameworks like React, Angular, Vue, Ruby, and more. No longer does a developer have to be crutched by WordPress requirements.

Headless still gives the user all the same power they had before vs. a traditional WordPress approach. You can still manage content, upload images, videos and more, but now you can access that information at anytime from anywhere.

A diagram illustrating a headless CMS vs. traditional CMS

Key differences between a headless CMS vs. traditional CMS

While developing in your preferred language is definitely a benefit if you’re making the leap to headless, there are several other differences as well. 


A headless CMS allows you to better protect your site from security vulnerabilities that inherently exist with a traditional WordPress setup. You can throw your WordPress installation on a private server that the end user doesn’t access and hit the API from a completely separate whitelisted server that hosts your web application. This cuts down on many of the usual WordPress vulnerabilities, including brute force attacks, file inclusion exploits, SQL injections, cross-site scripting, and malware.


A headless solution provides more opportunity to scale without bloat. For a rich user experience, users often lean on site generators like Elementor to create their WordPress front-end. However, over time these tools have become so massively large and resource heavy they cause large performance issues on load. We have observed desktop and mobile performance scores decrease recently as these plugins update.

With newer projects like React, you can manage smaller front-end builds, static site generation, and an overall lighter design infrastructure than the heavy front-end that exists with WordPress. 

Better DevOps

One of the large selling points of headless is a better DevOps experience. It’s easier to create and manage a continuous pipeline and git flow when working with a traditional web application. This allows you to keep the front-end managed easily and at most you merge databases between a testing and production environment for WordPress using something like WP Engine.

When not to go headless

Though a headless solution offers quite a few advantages, there are certain times when we look at a headless CMS vs. a traditional CMS, traditional wins out:

  • You plan to hand the project off to a non-technical user. If the site will be maintained by a non-tech user who plans to add content and change layouts over time, this is where WordPress shines on its own.
  • You are wary of managing twice the resources. Going headless means double everything: servers, resources and more. You must split a web server out and add a hosted instance of WordPress, which can be daunting and sometimes more complex than is needed.
  • You want to avoid the potential for more maintenance. WordPress has a diverse library of plugins for basic features that are necessary for a functioning visible site. When you decouple your front end from your CMS, you lose a lot of popular plugin support.  While some popular plugins have shifted support over to headless on top of their normal function and this looks promising for the future, it’s been a slow shift so far.

Is a headless CMS right for you?

Ultimately, the decision for going headless is up to the needs of the developer and the project.  If you want the ability to scale without performance restrictions (but need the ability to manage content in an already created and standard way), a headless CMS is a great option.

How to Manage an Effective Digital Transformation in Changing Times

Tech leaders are facing new challenges in 2022: more pressure than ever to keep systems thriving in the midst of huge technical demand… and the threat of losing the skilled labor required to do it. In this exclusive series, we’ll share some key takeaways to help tech teams stay agile:

  • Why digital transformation is an insurance policy against attrition and change
  • How to identify and manage the technical debt that threatens employee productivity and fulfillment
  • How DevOps practices can liberate and improve tech teams
  • The playbook we use ourselves at MercuryWorks to create painless digital transformations for our enterprise clients
strategy planning for a custom application

When MercuryWorks’s clients need content management for their web solutions, one of the decisions we guide them through is choosing the right content management system (CMS) for their needs. 

While end-to-end digital experience platforms (DXPs) may be the “new hotness,” many B2B and B2C enterprise solutions still need traditional content management. Sometimes a full-featured, heavy duty, end-to-end licensed CMS platform such as Adobe, Sitecore or Acquia is necessary, but other times it is not. In fact, sometimes the scale, scope and weight of these types of solutions can become a hindrance in the success of the web solution. Some websites can be highly effective with a relatively basic, lightweight platform.

In those cases, we often recommend WordPress for enterprise CMS use.

WordPress began as a blogging platform in 2002, but a lot has changed in the nearly 20 years since its creation. Today, it powers 34% of all websites in the world (including 14.7% of the world’s top websites such as The Walt Disney Company, TechCrunch, and BBC America).

WordPress has grown up and grown into a stable, secure CMS for many content delivery needs. Moreover, WordPress can be used as an effective headless CMS platform integrated into web applications.  We often hear clients’ initial concerns about WordPress for enterprise—and in many cases, what used to be problematic about WordPress just isn’t the case anymore.

Here’s what’s changed.

wordpress plugins for an enterprise website

Better Hosting Environments for Enterprise Business

WordPress is (and always has been) an open-source platform, which offers many benefits but has also made it historically vulnerable to security breaches. These problems were compounded by traditional hosting environments, where up to thousands of websites were hosted on a single server—relying on the host’s default firewalls and malware scans and making all websites on that server susceptible if one website’s security was breached.

Modern hosting environments, however, are built with WordPress in mind. Managed WordPress hosting is a service offering all its own, with companies like WP Engine and Pantheon redefining the technologies upon which WordPress sites should be built.

 In addition to hosting your website on a private or semi-private server, managed WordPress hosting provides threat detection and alerts, automatic patches and minor updates, and security best practices such as SSL certificates, disaster recovery, plug-in approval and recommendation, and multi-factor authentication to protect your site. 

Managed hosting environments can also offer functionality to improve speed and performance, such as different development/staging/production environments, versioning, caching, CDNs, and highly scalable architecture to handle surges in traffic. Building WordPress sites on more stable environments significantly reduces their vulnerability and allows teams to enjoy the lightweight, open source benefits of WordPress without assuming unnecessary risk.

A More Robust Platform

WordPress offers an easy-to-use WYSIWYG editing interface, allowing non-technical editors to upload and publish content without engineering support. While it may not offer all the bells and whistles (or the expense) of a full-scale DXP, the platform is quite mature and full-featured, especially for an open-source CMS platform.

By updating features and adding more robust tooling over time, WordPress has hardened into a more mature product suitable for enterprise content management. More out-of-the-box functionality means fewer plugins and greater stability; one recent example is the WordPress Gutenberg block editor first introduced in 2018, which in some cases has eliminated the need for separate “page-building” plugins. 

Just in the past few years, WordPress has also added accessibility and performance improvements such as color contrast settings and lazy loading, along with data privacy enhancements to allow companies to maintain regulatory compliance. With an average of two to three updates each year, WordPress has demonstrated a reliable maintenance and support schedule and is responsive to the evolving needs of its users.

A Mature Open-Source Ecosystem

Not only has the platform itself and its hosting environments matured over time, but so has the WordPress ecosystem. There are more than 50,000 WordPress plugins currently on the market—and while their quality may vary, the number of stable plugins with good support has never been higher. WordPress’s continued dominance in the CMS market and its mature codebase and feature set has fostered an industry of highly trained professionals and development partners, along with more mature processes and best practices.

Headless CMS for App Integration

In enterprise cases where a traditional CMS may not work well or be too restrictive, WordPress can be used as a “headless” CMS.  For example, when doing mobile-oriented development, you can easily use API calls in a headless CMS to deliver content to a Progressive Web App or React Native platform. Similarly, you can make use of JavaScript frameworks in your apps and rely on headless CMS architecture for pushing content to various platforms. 

Among other benefits, WordPress for enterprise as a headless CMS already has REST API built in, which means we have the API part sorted. Furthermore, we can make use of the familiar WordPress admin to manage the content.

Choosing a WordPress Development Partner

Companies in need of content management no longer have to choose between WordPress’s ease of use and the stability, support, functionality, and performance of other solutions. At MercuryWorks, we leverage the best of WordPress—from superior hosting environments to multisite installs to sophisticated front-end frameworks—to create lightning-fast, flexible, and secure websites for enterprise.

The Ultimate (Non-Techy) Guide to Building Custom Software

Building custom software for your business doesn’t have to be intimidating. Over five small lessons, we’ll clearly explain everything you need to know to feel empowered in your first conversations with a development partner:

  • A beginner’s guide to key development terms and concepts
  • How to tell if you really need a custom software solution
  • What should happen before your developer writes a single line of code
  • What to expect during the development process
  • How to choose the right development partner for your project and budget

For a long time, hosting an application was constricted to server racks inside the same building as the company developing the web application. Scaling an application that is hosted in an internal environment has several challenges, ranging from equipment costs to physical space in a server room to the hours needed to replicate everything needed for the application. 

Thankfully, Azure’s cloud infrastructure has made scaling up and scaling out an application very simple. 

In this article, we’ll cover when and why you should scale your application with Azure, and then we’ll walk you through exactly how to do it.    

Azure allows businesses to scale their applications more easily than on-prem infrastructure.

Why Scale Your Application?

When you begin building an application, you may have grand plans for it to be adopted by thousands, if not millions, of users.  Realistically, applications typically start off with a modest user base and grow over time, with rates of growth varying significantly by business.

As your application continues to grow, keeping your original architecture in place could start to produce a poor user experience. At this time, it’s probably time to consider scaling the architecture hosting your application. Below are a few reasons why scaling is a valuable tool when hosting your application in a cloud-based environment. 

1. Improve Performance

Over time, your application may experience performance issues. This can be caused by high traffic volume, memory consumption, or complex logic taxing the CPU. When this happens, the first reaction is often to throw more resources at the problem. Azure offers the ability to scale up and scale out on a wide variety of assets in their suite of products. This provides a quick, simple way to add more performance to your application or split that high traffic volume with ease. 

2. Prevent Application Outages

Once you have your first production outage you start thinking of user experience and uptime.  This is a very good reason to have an application that can quickly and easily scale.  You want to make sure that your user base can access your application at any time.  Having multiple instances up and running allows for an issue to occur and your application still remains accessible.

3. Optimize Global Access

Another good reason to scale your application would be your user base. If you have users all around the world then you do not want to be stuck to a single region in Azure. By limiting your application to a single region, you are limiting yourself from providing the best user experience possible for a subset of your user base. 

When your application needs access on a global scale, it is essential to ensure your application is located across several different regions in Azure. For example, MercuryWorks works with a client that has a global user base of physicians in need of ocular tissue for their patients. Global access was an important factor when we established their infrastructure.

When Should You Scale Your Application?

Now that the Why is out of the way, the next question should be When.  Depending on your philosophy for deployment, this question will come up in the beginning of your development lifecycle or potentially the first time you hit a major issue that needs immediate attention. 

At Mercury, we partner with clients to help them anticipate what their needs will be at the onset of development and over time. We do this by modeling the client’s potential needs (if building from scratch) or reviewing the current performance metrics (if working on an existing application).  From there we make recommendations for the optimal MVP-based architecture, knowing that scaling is always an option as the application gains adoption.  

When it comes to different application scaling techniques, scaling up or scaling out typically depends on the volume of traffic on your application:

  • Scaling out is the right solution for you if you are seeing very high traffic that is causing your application resources to spike. Scaling out will take your application and clone it as many times as necessary, all while adding a load balancer to make sure traffic is spread out evenly. 
  • Scaling up is the best approach if you have low traffic activity but are still seeing resources peak to 100%. Scaling up allows you to quickly add more resources to your application to allow it to process normally under highly stressful executions. 

Both options are powerful tools in your arsenal, and neither take very long to accomplish. The act of configuring Azure for either is a few clicks and the processing time for Azure is a few minutes max. 

How Can You Scale a Web Application?

A great solution for hosting web applications is Azure’s Platform as a Service (PaaS) architecture.  It provides a lower maintenance cost because you do not need a Network Admin running updates each week to make sure you are up to date.  It also provides a very quick scaling option should you decide your application is not performing up to your expectations. 

In this section, we are going to walk through how easy it is to scale your application. Azure has several assets that can help you quickly and easily scale your application with a few clicks of a mouse. Here we use Azure App Service and Azure SQL Database.  They both have the concept of “Scale Up,” but App Service has the added feature called “Scale Out.” 

scaling out vs scaling up in azure

Scaling Up

Scaling Up is the classic answer to a technology problem, which is to throw more resources at the situation until it resolves itself. All Azure assets have different pricing tiers that can provide various levels of resources depending on your needs.  Below is a screenshot of what you will see when you are working to scale an Azure SQL Database: 

Azure standard scaling up

As you can see, there are several options to choose from when making your decision. Azure SQL Databases have 3 tiers of performance: Basic, Standard, and Premium. Each tier allows the database to have a maximum number of resources available.  To scale this type of resource, you simply pick the category that fits your needs, adjust the sliding scale to add/remove resources, and click Apply. 

Azure sliding scale for scaling up

When it comes to Azure App Service, the scaling process is more direct. When you select the “Scale Up” option located in the navigation you will be taken to a slightly different screen layout.  You still have 3 tiers to choose from, but this time you have set options to pick instead of sliders.  As you can see in the screen shot below, this blade also shows you the currently selected resource package.  To change your currently selected package, all you need to do is select a new version and click Apply. 

Azure App Service pricing tiers

Scaling Out

Scaling out is a special option available to Azure App Service. This feature allows you to create one or multiple clones of your existing application to better balance traffic or resource load.  Essentially, it’s like creating multiple App Services that all live behind a Load Balancer. The Scale Out feature is available in two methods, Manual Scale and Custom Autoscale. Both can help you accomplish your goal of allowing your application to be more performant for your users. 

Manual or autoscale options in Azure App Service

Manual Scale is just as it sounds: you’ll be given a simple slider that will tell Azure how many active instances of your application you want available. But Custom Autoscale is where the magic really happens. Here you can define a wide range of requirements for your application to be scaled out for you. Azure has over 20 different options you can choose that will let you define upper limits for when your application should scale on its own! 

Autoscale configurations in Azure

Making Scaling Easier

With the push to cloud-based hosting, having a quick and easy method to scale your applications is very critical.  Azure provides the tools necessary to achieve this expectation with some of its most popular PaaS offerings. The best course of action is to start early and have a plan in place.  Azure provides excellent automation tools and alerting that will allow to gauge when the time is right to scale your application and bring it to the next level. 

How to Manage an Effective Digital Transformation in Changing Times

Tech leaders are facing new challenges in 2022: more pressure than ever to keep systems thriving in the midst of huge technical demand… and the threat of losing the skilled labor required to do it. In this exclusive series, we’ll share some key takeaways to help tech teams stay agile:

  • Why digital transformation is an insurance policy against attrition and change
  • How to identify and manage the technical debt that threatens employee productivity and fulfillment
  • How DevOps practices can liberate and improve tech teams
  • The playbook we use ourselves at MercuryWorks to create painless digital transformations for our enterprise clients
strategy planning for a custom application