AWS

Continuous improvement – server access example

When you work with any of the big public cloud providers, one thing is for sure – there will be many changes and improvements to the services that they provide to you. Some changes may perhaps change the way you would architect and design a solution entirely, while others may bring smaller, but still useful improvements.

This post is a story of one of these smaller improvements. It is pretty technical, the gist of it is that with a mindset of continuous improvement, we can find nuggets to make life easier and better and it does not have to be completely new architectures and solutions.

A cloud journey

In 2012, before TIQQE existed, and when some of us at TIQQE started our journey in the public cloud, we created virtual machines in AWS to run the different solutions we built. It was a similar set-up to what we had used in on-premises data centres, and we used the EC2 service in AWS.

Using VPC (Virtual Private Cloud) we could set up different solutions isolated from each other. A regularly used pattern used back then was a single account per customer solution, with separate VPCs for test and production environments. These included both private and public (DMZ) subnets.

To login to a server (required in most cases, not so much immutable infrastructure back then) you needed credentials for the VPN server solution, with appropriate permissions set up. To log in to an actual server, you also needed a private SSH key. One such SSH key is the one which you select or create when you create the virtual machine, for the ec2-user user.

While this worked, it did provide some challenges in terms of security and management – which persons or roles should be able to connect to the VPNs, which VPCS should they be able to access? Of those users and roles, who should be able to SSH into a server and which servers?

There was a centrally managed secrets store solution for the SSH keys for the ec2-user user and different keys for different environments and purposes, but this was a challenge to maintain.

Serverless and Systems Manager

The serverless trend which kind of started with AWS Lambda removed some of these headaches since there were no server access or logins to consider – at least not where solution components can be AWS Lambda implementations. That was great – and still is!
Going serverless can provide other challenges, and it is not the answer to all problems either. There is a lot to say about benefits with serverless solutions. However, this story is focusing on when you still need to use servers.

AWS has another service, called Systems Manager, which is essentially a collection of tools and services to manage a fleet of servers. That service has steadily improved over the years, and a few years back it introduced a new feature called Session Manager. This feature allows a user to login to a server via the AWS Console or via the AWS CLI – no SSH keys necessary to be maintained and no ports to configure for SSH access. This feature also removes the need for a VPN solution for people who need direct access to the server for some reason.
Access control uses AWS Identity and access management (IAM) – no separate credential solution.

Some other major cloud providers already had similar features, so in this regard, AWS was doing some catch-up. It is good that they did!

A new solution to an old problem

For a solution that requires servers, there is a new access pattern to use. No VPN, no bastion hosts. Those that should have direct access to a server and login to that server can now login directly via the AWS Console in a browser tab. No VPN connections, no SSH keys to manage –  only select to connect log in to the server via the browser.  That is, assuming you have the IAM permissions to do so!


For those cases that the browser solution is not good enough, it is still possible to perform an SSH login from a local machine. In this case, it is possible with the help of the AWS CLI to make a connection to a server using Systems Manager Session Manager. The user can have their SSH key, which can be authorized temporarily for accessing a specific server.

Since it is then possible to use regular SSH software locally, it is then also possible to do port forwarding for example, so that the user can access some other resource (e.g. a database) that is only accessible via that server. AWS Systems Manager also allows for an audit trail of the access activities. 

Overall, I believe this approach is useful and helpful for situations where we need direct server access. The key here is though, with a mindset of continuous improvement – we can pick up ways to do better, both big and small.

Cloud strategy

We all need a CFS – you too!

My own datacenter or move to the cloud? That’s the question. A “close call” some say. A “slam dunk” for the cloud I say. The question was perhaps relevant five years ago, but not today. Today the question should be; Why not in the cloud? The first step is a Cloud First Strategy. No more excuses. You have the recipe here.

There is much that suggests that a Cloud First Strategy – a CFS in TIQQE language – is the best for all companies and organizations. But what does a Cloud First Strategy actually mean?

For us at TIQQE, it simply means that if there is an opportunity to use the cloud and there are no barriers of the type of legal, technical or unreasonable customer requirements, then it is the cloud that rules. Pronto. Period. Basta! When you five years ago had to argue repeatedly to move something in to the cloud and often got a NO. Today it should be just as difficult to get a YES to stay in your own data center without overwhelming evidence that it benefits the business and facilitates the customer experience.

Classic arguments against the cloud that it is expensive and that the cloud is not secure are today arguments that should be heavily questioned when presented. TIQQE has covered these two arguments, opinions or myths into two blog posts; Is The Cloud Secure? and The Cloud is Expensive.

If we go back to the question posed above; What does a Cloud First Strategy actually mean? In this blog post I will sketch the foundations of a Cloud First Strategy (CFS). All a result learned together with our customers over the years.

The CFS (and for the last time – Cloud First Strategy) is by nature something to follow when creating some new systems or services or when refactoring older legacy systems or services. It’s an important strategy to have when moving away from an on premise IT environment, to a cloud-based one. It helps to manifest ambition and direction and give guidelines in decision making. But it also stands entirely on its own for new development of systems and services. Whatever the case, it is an important tool for establishing a Cloud First mindset and point out the direction.

When creating your CFS, it is basically one question that must be answered first. It is about the degree to which the new service or system has the potential to differentiate you (give you competitive advantages) in the marketplace vis-à-vis competitors and other industry players.

In a CFS, there are two principles that will guide you in finding the answer on that question. If the service or system you consider to develop or want to refactor:

  • does not differentiate you in the marketplace, you should choose to BUY SERVICES IN THE CLOUD to solve the task (so-called SaaS – Software-as-a-Service)
  • differentiates you in the marketplace you should choose to BUILD IN THE CLOUD to create your own ability to focus on the business benefit and the power of innovation in your business that the cloud provides

As stated above, there are two different ways to answer the question. But both paths lead to the cloud. A true CFS. But a CFS cannot work in a vacuum. It must also work for companies older than ten years and who were not cloud native when founded. To supplement, some type of guidance is needed in order to help making the right decisions. This priority staircase can look like this. It is listed in the order you should consider the different options when making decisions.

  1. SaaS (Software-as-a-Service) – Always start with this option and choose a SaaS solution for the system or solution you are considering if it has no potential to differentiate you in the marketplace. The SaaS option is the preferred alternative for non-market differentiating applications. Can be about internal support systems for standardized processes as well as parts of solutions that are close to customer experience but which have no potential to make the customer experience unique.
  2. Greenfield – This is the preferred alternative in the CFS when you considering systems and solutions where building unique customer experiences has a potential to differentiate you in the marketplace. Best done by building directly for the cloud with agile development methods and self-sufficient DevOps team. All in order to maximize the innovation speed and utilize all the benefits of building for the cloud and create agility and resilience towards market changes.
  3. Data Center Expansion – Applications developed by teams that need operational support or where close integration with on-premises is needed. The expansion in to the cloud is the preferred choice in this alternative.
  4. On Premises – Only an option that shall be considered if there are legal, technical or customer requirements that makes it impossible to utilize the cloud. An advice is to see this alternative as the last resort. Requirements can be discussed with the other parties in general.

By basing a CFS on the above principles and priorities, we capture not only the appealing features of the cloud that Cloud Native companies benefit from all ready from start, but also the complexity that every organization has that was not founded when Cloud Native was the tune.

For me, it is obvious that every organization that wants to be relevant in their marketplace in three to five years must have a CFS established. Why not do it now and take the lead in your market today. Instead of standing left behind when the train leaves the platform! No excuses. You have the recipe above!