I knew that TIQQE worked with Amazon Web Services and that the company strived for a good company culture, which basically was what made me interested. I was looking for a job with something interesting to work with (AWS) and where I would enjoy going to work everyday and TIQQE ticked both those prerequisites off. I also knew Jacob (TIQQE’s CEO) from before, and knowing how good of a person he is, I also knew that TIQQE would be a great place to work at since he worked there!
What was your first impression of TIQQE your first week? Since we’ve been working from home the whole time it’s been a bit different compared to other jobs, but I’m also quite used to talking to people through Slack, Google Hangout and similar services so I didn’t think too much about it. But we started off with a couple of meetings and introductions during my first days so I got into contact with multiple colleagues straight away and got assigned a mentor that has been very helpful.
What is your role at TIQQE? Full Stack developer, currently working with PostNord.
How has your first time been at TIQQE? It’s been great! Everyone at TIQQE has been very nice and friendly, and I’ve gotten into a great team at PostNord. It’s a lot of fun and rewarding to work with something that is used daily!
What are you looking forward to in the nearest future? I haven’t thought too much about that – since I just recently joined both TIQQE and the team at PostNord I’m just trying to get up to speed with everything and do my best!
What do you know about TIQQE now?
That it indeed is a great company, and I’m very happy that I joined! Looking forward to see what the future brings!
If you want to read why Joakim joined TIQQE follow the link here!
Edwin is an innovative web developer who manages all aspects of the development process. He’s passionate about solving problems, creating ideas, and learning new technologies. He has a lot of experience working on different technologies such as Python, PHP, Typescript, Angular, VueJS, Docker, and so much more. He is more focused on backend development, and how to automate things.
When not at work, Edwin loves biking and motorcycle riding. He also loves playing MMORPG games and spending time with his family. For Edwin, work, hobbies, and family should be well-balanced.
What is required to build a sustainable organization, where employees choose to stay and where they can develop in an innovative environment? How can we make employees feel “this is the last company I will work for”?
Last week we listened to the first part of the podcast where we got to know Joakim and he covered: why sneakers are the best to wear, why a pizza oven should be in used in every household, the importance of taking a nice nap and what it was like to work on “the dark side “. He will also share his insights and experiences on how to build a sustainable community where the people choose to stay. And create an innovative environment where people who are part of the community feel that this will be the last company they will ever work for.
The second part of “Culture and innovation”, we will delve into culture and innovation – the symbiosis between them and how important it is that they exist within the organization. Joakim also shares his top 5 list of books to read.
We are proud to welcome Bring as a new customer toTIQQE. Bring has chosen TIQQE as their Integration partner for onboarding customers.
Bring solves everyday logistics for small and large businesses in the Nordic region, through efficient and sustainable deliveries. Bring handles parcels, goods and couriers, and can assist their customers with both small and large deliveries in the entire Nordicregion, both regionally and internationally. Together with you, Bring will find the best solution for your business – to you or directly to your customers.
Following a strong growth in e-commerce, Norway Post and Bring are now making major investments in what will be Norway’s largest fully automated warehousing solution.
This new warehousing solution, together with new digital solutions and automated processes, will take care of all logistics from the moment the customer presses the buy button in the online store up until the item is delivered. The parcels will be picked up and delivered to online retailers throughout Eastern Norway until nine o’clock in the evening.
This creates a large demand for automation and in 2020 TIQQE was chosen to be Bring Warehousing’s Integration partner.
Bring looked for a partner who will be able to work together with them on their journey, and that can provide help and support when and where it will be needed. This is where TIQQE comes in. We’re proud and honored to be part of Bring’s journey and look forward to a long-term partnership!
Last week TIQQE’s Joakim Restadh was a guest at ZervicePoints Podcast.
He will share real life experiences both from the past and present and most importantly the lessons learned down the road.
In the first part we will get to know Joakim where he will share: why sneakers are the best to wear, why a pizza oven should be in used in every household, the importance of taking a nice nap and what it was like to work on “the dark side “. He will also share his insights and experiences on how to build a sustainable community where the people choose to stay. And create an innovative environment where people who are part of the community feel that this will be the last company they will ever work for.
The second part will be connected to “Culture and innovation”, we will deep dive into culture and innovation – the symbiosis between them and how important it is that they exist within the organization.
Joakim also shares his top 5 list of books to read.
AWS has released a new AWS SSO application in the Azure AD application gallery to make this configuration even easier! AWS has also worked with Microsoft to update the existing Azure AD gallery application names and descriptions to help people understand the difference between the use cases.
You have 3 different options to connect your Azure AD to AWS:
Use the AWS Single Sign-On Azure AD gallery application for multi-account access and single sign-on to the AWS Console, AWS Command Line Interface, and AWS SSO integrated applications.
Use the previous Azure AD gallery application, now named AWS Single-Account Access.
Use the AWS Console Access app for password vault sign-in to the AWS Console in a single account.
In this blog-post, I will go through option number 1 and follow you through the process step-by-step.
Organizations usually like to maintain a single identity across their range of applications and AWS cloud environments. Azure Active Directory (AD) is a common authentication method as Office 365 often is used among companies, and might be the hub of authentication as it often is integrated with other applications as well.
If you are using AWS Single Sign-On (SSO) you can leverage your existing identity infrastructure while enabling your users to access their AWS accounts and resources at one place. By connecting Azure AD with AWS SSO you can sign in to multiple AWS accounts and applications using your Azure AD identity with the possibility to enable automatic synchronization of Azure AD Users/Groups into AWS SSO.
This makes perfect sense and often improves your ability to further automate how you handle user-lifecycle and access to your AWS accounts as you might already have some identity manager connected to your HR system like Microsoft Identity Manager or Omada in place for example. You can also leverage your existing process for applying for access to different systems, ServiceNow or similar solution might already be connected to Azure AD in one way or another which then could be leveraged for applying for access to different AWS Accounts. There are also other benefits such as levering your existing MFA solution if your organization has such a solution in place.
To the good stuff! I will in this blog-post demonstrate how you can connect your Azure AD to AWS SSO and take advantage of its capabilities.
Creating a new Azure Enterprise Application
Login to your Azure portal and open Azure Active Directory. Under the Manage section, click on Enterprise application.
Click New application and search for “AWS” select AWS Single Sign-on, give your new application an appropriate name and click Create.
Once the Azure gods have created our new application, head into the Overview page and select Set up single sign-on and choose the SAML option.
Under section, SAML Signing Certificate click Download next to Federation Metadata XML.
Please keep this page open as we later need to upload the metadata XML file from AWS SSO.
Setup AWS SSO
Login to AWS management console and open AWS Single Sign-On, please ensure that you are in your preferred region. If you haven’t enabled AWS Single Sign-On already, you can enable it by clicking Enable AWS SSO as shown below.
Click Choose your identity source. You can also configure your custom User portal URL if you’d like but it is not required.
Select External identity provider. Upload the AD Federation Metadata XML file downloaded earlier inside the IdP SAML metadata section and download the AWS SAML metadata file.
In the Azure SAML page, click Upload metadata file and upload the AWS SSO SAML metadata file.
If you have configured a User portal URL earlier, you need to edit the Basic SAML Configuration section and match the Sign-on URL.
Setting up automatic provisioning
The connection between Azure AD and AWS SSO is now established, we can proceed to enable automatic provisioning to synchronise users/groups from Azure AD to AWS SSO.
Note that you can use Azure AD groups but not nested groups ie. groups that are into groups.
Head over to the Provisioning page and change the mode to Automatic. Please keep this page open as we will copy values from AWS SSO.
In the AWS SSO Settings page, click Enable automatic provisioning
Take note of both values given in the popup
In the Provisioning page in the Azure portal, expand the Admin Credentials section and insert the values from above. It is also recommended to add an email address for notification of failures.
Note that these tokens expire after 1 year and should be renewed for continuous connectivity.
Click Test Connection and it should result in a success message.
Expand the Mapping section and click Synchronize Azure Active Directory Users to customappsso
Which attributes you want to sync over depends on your setup, but default setups you can remove all attributes except: userName active displayName emails name.givenName name.familyName
You then create a new attribute mapping objectId with externalId.
Important to note is that you can modify the email attribute to use userPrincipalName over mail as not all users have Office365 licenses which leave that attribute null.
In the Provisioning page, you can now set the Status to On. It is recommended leaving Scope set to Sync only assigned users and groups. Click Save, it should take about 5 minutes for it to start synchronizing.
Our AWS SSO and Azure AD connection is now fully set up, when you assign Azure Users/Groups to the enterprise app, they will then appear in AWS SSO Users/Groups within around 40 minutes.
Creation and assignments of AWS SSO Permission Sets
Using Permission Sets, we can assign permissions to synchronized Groups and Users, these permission sets will later create IAM roles in accounts which they are assigned. You can create new Permission Sets based on AWS Identity and Access Management (IAM) managed policies or create your own custom policies.
To create a new Permission Set in the AWS Management console you can follow the below steps:
Go to the AWS SSO management portal, in the navigation pane, choose AWS accounts and then the AWS organization tab.
In AWS account, choose the account that you want to create a permission set for, and then choose Assign users.
In Display name, choose the user name that you want to create the permission set for, and then choose Next: Permission sets.
In Select permission sets, choose Create new permission set.
In Create new permission set, choose Use an existing job function policy or Create a custom permission set depending on your needs, click Next Details, and then select a job function or create a custom policy or managed policy.
You can then complete the guide and click Create.
You should then see the message “We have successfully configured your AWS account. Your users can access this AWS account with the permissions you assigned”.
But be careful on how you deploy these AWS SSO Permission Sets and assignments since it needs to be executed in the Master account. You should always follow the least privilege principle and should therefore carefully plan on which approach you use to deploy these Permission Sets and assignments. If you want to automate assignments and creation of Permission Sets further, I suggest you go with an event-based approach and assign Permission Sets using Lambdas.
In this blog-post I showed how you can connect Azure AD to AWS Single Sign-On (SSO), you can now manage access to AWS accounts and applications centrally for single sign-on, and make use of automatic provisioning to reduce complexity when managing and using identities. Azure AD can now act as a single source of truth for managing users, and users no longer need to manage additional identities and passwords to access their AWS accounts and applications. Sign in is accomplished using the familiar Azure AD experience, and users will be able to choose the accounts and roles to assume in the AWS SSO portal.
You now also have the possibility to use your existing automation process on how you apply for access, grant and revoke access to systems.
If you have any questions or just want to get in contact with me or any of my colleagues, I’m reachable on any of the following channels.
What tools are available if I want to start building my own serverless applications? We will go over some of the most popular frameworks and tools available for the developer who wants to get started with AWS Lambda.
There are a lot of tools out there to use when building software that are powered by AWS Lambda. These tools aim to ease the process of coding, configuring and deploying the Lambdas themselves but also the surrounding AWS infrastructure. We will discuss the following alternatives:
AWS Cloud development kit (CDK)
AWS Serverless Application Model (SAM)
About AWS CloudFormation
AWS CloudFormation is a service within AWS that lets you group resources (usually AWS resources) into stacks that you can deploy and continuously update. These CloudFormation templates are written in JSON or YAML and manually typing those can be very tedious. Especially when your stack grows to a lot of resources that reference each other in multiple ways. What lots of these frameworks and tools do is to provide an abstraction layer in front of CloudFormation so that the developer can more rapidly create and focus on the business value of the service they are building.
AWS Cloud development kit (CDK)
The AWS CDK went into general availability in the summer of 2019 and has been getting a lot of traction lately. It is an open source framework that lets you create your infrastructure as code instead of CloudFormation. You then generate CloudFormation templates from your code by running the command cdk synthesize.
This one has been around since 2015 and was called JAWS before quickly changing to its current name. As the very descriptive name says, it’s a framework for building serverless applications! The framework is easy to get started with and setting up an API with a few Lambdas require very little configuration for the developer as the framework takes care of the underlying CloudFormation template.
Because of its specific focus in serverless applications, the framework is not as broad as the CDK and that comes with pros and cons. You will get a lot of help if you are setting up Lambdas or events that trigger those Lambdas, but setting up the surrounding infrastructure such as queues, tables, kinesis streams and cognito user pools will often require you to write pure CloudFormation. At TIQQE, some of us like to create and deploy this surrounding infrastructure with the CDK, while developing the Lambdas and the API gateway in Serverless Framework.
Serverless Framework is open source and multi-cloud. It’s also extendable with a wide range of plugins created by the community.
AWS Serverless Application Model (SAM)
AWS SAM is another framework similar to Serverless Framework that it let’s the developer write less code when building serverless applications. Unlike Serverless Framework, SAM is specific to AWS and its main configuration file template.yml is written with CloudFormation. So if you have previous experience with AWS and CloudFormation you will likely find it easy to get started with SAM. A neat feature in SAM is that it has support to deploy APIs using swagger out of the box.
This multi-cloud tool for infrastructure as code is worth a mention! It has been around since 2014 and is written in Go. For AWS it uses the aws-sdk to manage resources instead of CloudFormation, which gives the benefit of not having a resource limit of 200 that AWS impose for CloudFormation templates.
How do I choose which one to pick?
It comes down to some characteristics of your application, and a fair bit of personal preference!
Are you building a service with an API endpoint and you have little or no previous experience in AWS or serverless architecture? We recommend you to check out Serverless Framework.
Are you not a fan of writing CloudFormation and your architecture needs a lot of infrastructure? Check out AWS CDK.
Are you familiar with CloudFormation and want to get started with serverless applications? AWS SAM could be the perfect match!
There are countless forum posts and articles debating whether to go with AWS SAM or Serverless Framework. The frameworks are very similar and many times it comes down to personal taste. At TIQQE we have lots of experience working with Serverless Framework and some of us would debate that you get the job done in less lines of code with Serverless Framework. With that said, SAM does not have to worry about being generic for multiple clouds and that can be an edge if you are working only with AWS. SAM also defaults to giving Lambda functions least privilege access rights (AWS best practice), while Serverless Frameworks share a role between all Lambdas.
Terraform can be a good match if you are creating infrastructure as code across multiple clouds. While Terraform is capable of doing many things, it is not specialised in serverless technologies and you will have to write a lot of code to achieve the same results as the other frameworks described in this post. Not having a 200 resource limit is nice but should not be a problem that often if you are designing your systems in terms of microservices.
Do you have any comments or questions about this article? Please reach out!
The 8th March Johan Karlsson joined TIQQE. After two weeks with us we asked a few questions to see if the reasons he had to join us have been met so far.
What did you know about TIQQE before you started? I worked at Enfo when TIQQE was founded and I’ve kept on eye on the company ever since.
Why did you want to join TIQQE? Because I believe in what the company stands for and because several friends and former colleagues already work here. I wanted to have a lot of smart, inspiring tech nerds around me and I like the technologies that TIQQE work with.
What was your first impression of TIQQE your first week? There is a warm and friendly atmosphere here. We’ve been a few people at the office which helps with the intro. It has felt like a big re-union.
What is your role at TIQQE? Developer and tech lead.
How has your first time been at TIQQE? I’ve got a good introduction to people, processes and tools by Cajza. Clearly I’m used to working remote but starting from scratch remote is a bit different. A lot of new things to learn.
What are you looking forward to in the nearest future? I’ve started in the PostNord retail team. I’m looking forward to learning the business side, learn AWS, getting to know the team better and whole TIQQE.
What do you know about TIQQE now? It’s as nice I hoped it would be.
We have entered the last month of the first quarter of 2021.
In this blog we would like to share what we are seeing in the market and what we predict for 2021. Prediction is always difficult and depends on where you are getting your data from, but we are looking at what we are hearing within the market, from customers, potential customers, and of course market analysis.
In the Swedish market since 2007 there has been a shift of IT-spend moving from central IT to business IT, and this year we see a reversal where business IT spend is moving back to central IT. We usually see this during a recession but now we are seeing this from the effect of Covid and the impact it has had on the market.
What happens when moving from Business IT to Central IT is that we are going from decentralized to centralized IT-Spend. The challenges that this creates is that the organizations have data across the business which increases the risks of security breaches, GDPR implications etc.
The question this raises is, what need will this generate in the market? And what we are seeing is a large uprise of needs for integration and security. Now when the trend is to centralize we need to of course enable control of the data and know where it is and most importantly that it’s secure.
At TIQQE we are amongst the market leaders within integration and work closely with many of our customers within this area. We develop our integrations which technically are state of the art but not dependent on expensive hardware, licenses, upgrade projects and most importantly you can get started straight away.
We call this service “Serverless Integration As A Service”. Please see blog for further details: Serverless Integration
So if you are facing integration challenges ahead, make sure to reach out!
We are proud to welcome ClearOn as a new customer to TIQQE. Clearon have decided to move their applications and infrastructure to AWS.
ClearOn promotes sales through smart campaigns and is a major developer of payment services and retail cash register services. Their focus is to offer services that create more value at checkout, and that increase in-store sales. They do this in close cooperation with the retail trade, suppliers and banks online with 5000 shops in their innovative system.
ClearOn have decided to move their infrastructure to AWS. When looking for a supplier, Clearon wanted to find a partner with extensive experience and are specialized within AWS.
They also looked for a partner who would be able to work together with them on their cloud journey and provide help and support when and where it would be needed.
Welcome to TIQQE, we’re looking forward to a long-term partnership!