andreas vallberg serverless integration

Serverless Integration

The integration landscape is changing and you are paying too much!

Serverless integration is our offering where we replace your traditional on-prem enterprise integration software with auto-scalable, fully managed, pay-for-what-you-use connectivity between your software applications on-premise and in the clouds.

Why serverless integration?

Enterprises has struggled with integration, where projects were setting up integration dependencies as part of the project and when the project closed down after delivery the integration dependencies were left in limbo with nobody to management.

Enter the era of integration software, where we established integration competence centers and purchased specialized software that was trying to make the integrations easier, deliveries faster and integrations manageable.

With 15 years in using enterprise integration software, We can see with a bit of hindsight that the promise of integration software has failed to deliver to us:

  • Visibility of the cost now cause integration to be a problem, instead of being spread out among the projects
  • Feature based selling of integration platforms often leave customers with a lot more features than they will make use of
  • Centralization leads to more structure, yes, but the structure comes at the cost of red-tape and more lead time for implementing solutions

So the solution to this was the Self service API’s – already touted by Jeff Bezos back in 2002 in his now-famous Mandate which sternly forced everyone into an API-first approach. Suddenly teams can consume other teams data and do integrations without talking to the intermediary.

Even though it is almost 20 years ago, we still see corporations trying to adopt this way of thinking, while also trying to save the Enterprise Integration Center.

A battle of many fronts

We see the Integration Competence Center concept being attacked on many fronts:

  • The software application owners and teams are building their own dependencies directly using API driven approach
  • Infrastructure is moving to the cloud, leaving no Servers to manage, cluster and consider
  • The different building blocks (i.e. features) of the old integration platform are becoming increasingly available from the existing cloud vendors rendering your integration software platform obsolete
  • Infrastructure is becoming code, Security Operations is becoming code.
    Why should the integrations reside in proprietary formats deep inside custom software which only a few selected people have access and knowledge how to manage

The way out

This is the challenge we at TIQQE has seen, and that is why we are providing integration-as-a-service in our unique way. Knowing that a big part of the integration work is in the details of the specifications and the major part of the integrations within an organization is very similar we have a different approach.

We provide fully managed integrations and we do this using software implemented in standard languages, on a well-known cloud platform using serverless patterns.

This means the integrations are built securely, with auto scaling from the start. It means we are using standard development tools and standard programming languages that already millions of developers know.

Governance is still key!

Our value add is not mainly focusing on the implementation of the integrations, but rather the management of the integrations and standardization of monitoring and handling them.

The freedom of building high-order value add systems as integrations, and the standardization comes as a support in terms of operational excellence, security, reliability, performance efficiency and cost optimization (Yes – those are the 5 pillars of well-architected framework from AWS).

Many of our customers have felt their integrations to be a black-box experience and they feel a lack of understanding of what they have and how it works. We are handling this by providing our Harbor solution, where you as a customer get full transparency to the documentation, the integrations and their health.

Business Impact

  • You will save money
  • No license costs
  • No hardware costs
  • No patching costs
  • No lock-in
  • Pay for what you use
  • Adapt to change

Please feel free to reach out to Jacob Welsh and let us speak about how we can help lower your costs, increase your business agility and provide insights into your integration landscape.We will set you free from all major integration platforms such as Microsoft Biztalk, Teis, WebMethod and many others.

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 economics

License to kill

Using commercial software and paying expensive licenses is old school and no longer necessary. Cloud provide you with flexibility and you only need to pay for what you use. No investments necessary.

In May I’m sure many of you, including myself, was looking forward to the release of the new James Bond film, with the famous slogan – License To Kill.

Unfortunately, due to Covid-19, this film premier has been postponed but the reality of License to Kill within IT-licenses and infrastructure has never been more important than now.

We are in contact with roughly 150 companies across Sweden every month, mainly to understand where the market is at this point of time and how we need to align to be able to meet the market with their challenges.

In the past few months the market has really changed, most companies are “pulling the handbrake” and cutting down their variable costs, freezing new initiatives etc. What comes to a surprise is the number of licenses many companies have, everything from Office365, different on-premise & cloud platforms which are based on traditional license models which are core based and very expensive.

When buying licenses, with a traditional license model, you buy a capacity up-front which you are planning to use during a longer term, usually between 1-5 years. Of course, during this period, you are able to “scale up” and purchase more cores. But overall you will always be paying for more than you need at the point of time of the purchase.

Traditional on-premise platforms when scaling will have the following effects:

  • Additional cores
  • Additional servers
  • Not fully utilized 
  • Generate additional costs

This is costing companies across the globe huge amounts of money which could be spent on better things or even in these uncertain times also saved.

Here are a few examples:

  • On-Prem infrastructure
  • Integration platforms, Enterprise Service Bus
  • API-Platforms
  • Identity & Access Management platforms
  • Service & Assessment Platforms

The list is long and most likely you are running one or several at your workplace today.

So what’s the solution?

Both from a license and an infrastructure perspective the Cloud is the obvious choice this enables you to both scale up and down. At TIQQE we purely focus on AWS and the capabilities to scaling, not paying up-front license costs, pay for what you need at this point of time are all the key points to moving to the cloud.

Ask yourself if you need to renew your licenses anytime soon. Do you want to buy more licenses or do you want a second opinion?

We have all the tools in place to quickly identify your costs today and what the costs would be if you would instead operate in the cloud.

This blog is mainly focused on a cost saving perspective but there are many more examples what the cloud provides you with.

I really recommend checking the following blogs out:

4 ways of reducing cost and increase liquidity

Tiqqe Talk

TIQQE TALK: State of the cloud

Where are Swedish organizations in terms of cloud adoption? How far have they come and are anything holding them back? Listen to Malin Andersson and Anders Eriksson giving their view of where the market is today.

The talk is in Swedish.

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!

Customers

Welcome NEVS to TIQQE!

NEVS, or National Electric Vehicle Sweden, is dedicated to fight climate change by not only providing electrical vehicles to the global market but also reducing the number of vehicles on the planet, e.g. by shared autonomous taxi pods. TIQQE will provide expertise in how to design and set up the cloud architecture for an end-to-end solution to connect the taxi pods with the user interface. We’re looking forward to work with top engineers in Trollhättan for the purpose of a better world for everyone.

Everyone in Sweden knows about the bankruptcy estate of Saab which was acquired by NEVS in 2012. NEVS is part of the Evergrande Group, ranked as number 138 on the Fortune 500 list of top global companies. The reason why NEVS exists is to fight air pollution, congestion and climate change according to NEVS vision – shape mobility for a more sustainable future.

NEVS is now executing a plan to bring the vision to life by building shared autonomous electrical vehicles which will be introduced to the market within the next few years.

TIQQE will develop and build a scalable and well-architected cloud infrastructure based on state-of-the-art serverless technologies and high-level cloud services. The infrastructure will serve as the backbone when monitoring, controlling and connecting the physical vehicles and the end-customers mobile apps as well as third party service providers in a groundbreaking consumer service.

Cloud economics

“Cloud is expensive”

This is a common opinion among IT managers today. In this post, we will discuss and compare on-prem costs vs. cloud from a more holistic perspective.

We talk with a lot of customers in our outbound sales activities and two of the most common opinions about the cloud is that it is not secure and it is more expensive. We will cover the security aspect in another post and focus this one on the cost part of cloud vs. on-prem.

Is cloud more expensive than running a datacenter on prem? It is not a simple question to answer and there are no generic answers, it depends on a number of factors and the comparison is not a simple task. Several factors needs to be taken into consideration. However, the fact that the majority of the IT managers we talk to consider cloud more expensive shows that the market is still in its early phase.

When asking a couple of follow up questions, it turns out that the comparison often consists of comparing the cost of a server with a similar specified workload in the cloud. That is a too simplistic comparison and the cost of a server needs to be put in a wider context of IT cost structures. When buying a workload from a public cloud provider, a lot of things are included in the cost such as:

  • Facilities
  • Electricity
  • Cooling
  • Support team
  • Insurances (business interruption)
  • Decommissioning, migration and disposals
  • Capacity planning headroom
  • Inflation
  • Discount rate (Internal Rate of Return)

A typical comparison of server costs (red) vs. cloud workloads (yellow). Cloud turns out to be much more expensive

Source: AWS Cloud Economics

A full cost comparison between a datacenter and cloud shows a different picture. Cloud is usually between 30-50% less expensive.

Source: AWS Cloud Economics

Even if a server is cheaper than a similar specified cloud workload, cloud is still more cost efficient than running a datacenter when considering all related IT costs.

Besides lower costs, there are other financial benefits for an organization to move to cloud, for example tied up capital and cashflow.

Cloud providers practice a subscription based business model which means that customers do not need to invest in infrastructure. Almost every organization today have infrastructure which is treated as inventories and an asset in the company balance sheet. The capital tied up in infrastructure could be used for more revenue generating capital investments instead of taking on more debt. There are also rumours around the accounted value of infrastructure assets. Some argue that as cloud providers continue to gain market share, infrastructure in datacenters will be valued less in an event of a financial audit. I can’t find evidence that proves that such a valuation is in practice but it doesn’t seem unrealistic in the future, outdated technology are simply valued less.

From a cashflow perspective, cloud services do not require any upfront investments such as refreshments of infrastructure or software which will have a positive impact on cashflow.

To summarize; yes, a single server is usually cheaper than a similar workload in the cloud but from a holistic perspective, taking all costs into consideration, cloud is much more cost efficient. According to our own experience when engaged with customers, we find potential savings of around 30-50%. Combined with capital and cashflow benefits, all companies should evaluate a transition to cloud.

Besides costs, another common opinion about The Cloud is that it’s not secure. Read Kennet Wahlbergs blog post “Is The Cloud secure?”.