Frilansbloggen Archives - Developers Bay

Why Infrastructure-as-Code Matter to You,

Why Infrastructure-as-Code Matter to You, Even If You Are Not a Hotshot Developer

What is the deal with infrastructure-as-code, why does it matter to you?

Infrastructure-as-code, governance-as-code, and other “as-code” terms all deal with a set of desirable properties and outcomes. These properties and outcomes include getting consistent, reliable, repeatable solutions of some kind – with (relatively) fast feedback and delivery.

If you run business solutions at a cloud provider such as Amazon Werb Services (AWS), this will matter to you.

For infrastructure-as-code, this typically means to quickly and reliably set up and update (cloud-based) infrastructure. This infrastructure is the IT foundation that many business solutions depend on to run in a good way.

Thus it is a benefit to handle this consistently and reliably. If business expands or disaster strikes – also have the whole process repeatable and quick.

What as-code means

The term “as-code” in infrastructure-as-code may lead you to think it is about writing computer software to build infrastructure.

While this is certainly one way of doing it, the term “as-code” is a kind of abbreviation of “where we use good software engineering practices to produce great outcomes for the business.” But infrastructure-where-we-use-good-software-engineering-practices-to-produce-great-outcomes-for-the-business is a bit of a mouthful, so the short form “as-code” stuck instead…

What kind of good software engineering practices are we talking about here?

Provide a human-readable and precise description, without ambiguity
Keep track of changes in these descriptions, so we know what changed and who changed it
Keep a version and release history of changes, with meaningful labels
Allow us to see what state of the descriptions were at a specific time or associated with a specific label
Be able to perform tests against an infrastructure description, to validate key elements of the descriptions
Have computer software that can parse and execute the content of the infrastructure descriptions, to produce desirable outcomes
An organizational structure that supports a way of working that fits with these concepts

Note here that only the second to last bullet point mentions computer software. Instead, it is mainly about practices that allow us to keep track of what we do efficiently. In addition, It is also about to allow the use of software tools to make this type of work more efficient, faster and eliminate human errors as much as possible.

One type of description I mention is certainly programming language code, as it has some desirable properties. But it does not have to be that.

For the most part, it will boil down to a textual infrastructure description, since this is something both humans and computer software tools may handle reasonably well.

Another vital part, sometimes overlooked, is that working with these tools and processes needs to be supported by the way people work and organize. If not, it is going to become messy no matter what.

What tools to use with as-code solutions

A vital tool is a version control system (VCS). It is also called a software configuration management (SCM) tool. Today, the most popular tool in this space is probably git, but there are many other tools also. Multiple hosting services can help you store and manage data using git – three prominent ones are Github, Gitlab, and Bitbucket.

Any tool that can create and edit text is valid to write the infrastructure descriptions. These tools could be anything from Notepad on Windows to more advanced tools, such as Jetbrains Intellij IDEA.

A useful set of tools that comes up a lot are those associated with Docker, which is a way to package (application) software to be provisioned to the infrastructure.

Tools to describe my infrastructure

Vital tools to work with infrastructure-as-code are the tools that understand the infrastructure descriptions. The examples here focus on Amazon Web Services (AWS) cloud infrastructure. Tools such as Terraform, Pulumi, and CDKTF work with other providers also. Common tools include AWS Cloudformation and Terraform, which uses textual configuration descriptions to describe the infrastructure. These can go into quite a bit of detail, which means they are very versatile. However, these tools can also get complex to use.

Simpler tools include AWS Copilot and AWS AppRunner. These tools focus on a more limited set of use cases for cloud infrastructure, but on the other hand, they are also overall simpler to use.

We also have tools that involve actual programming language code, such as AWS Cloud Development Kit (AWS CDK), Pulumi, and Cloud Development Kit for Terraform (CDKTF). All these allow infrastructure to be defined and described using programming languages. For developers who are used to coding, this can be great.

What tools should I pick?

I would argue that for the tools that describe the infrastructure, there may be four groups of people:

Developers, who only want to care about application solutions, not the infrastructure it uses
Developers, who want to care about the infrastructure
Operations and sysadmins people, who care about the infrastructure, and does not consider themselves developers
Other people

If you have people that fit all bullet points, you could pick any of these tools. The CDK + Pulumi tools should have some persons that fit the developer-who-cares-about-infrastructure to be a good choice. They can provide support for the other groups using these tools.

Operations and sysadmins people may consider AWS Cloudformation and Terraform as options, unless they want to dive into learning programming more in-depth.

Developers who mainly want to focus on application solutions may be served better by AWS AppRunner and AWS Copilot if they do not have the support from other groups – if their use cases fit these tools. This is probably the starting point for the “other people” group also if the other groups are not there to support them. However, there is still a need to understand the application software to run, so the “other” group will need some additional support – or prepare to learn some of the skills of the other groups.

What to do next

Start with tutorials for the simpler tools, like AWS AppRunner or AWS Copilot – the latter can even deploy AppRunner solutions as well. Pick a hosting service for version control system software, and get familiar with it. I would suggest starting with Github, even if this is not what you will use in the end. Github is the largest hosting service on the market, so there is plenty of example for it. Plus, you can sign up for free and use it.

Read more articles written by Erik Lundevall-Zara here.

Vill du veta mer om oss på Developers Bay?

Hur kan vi attrahera fler kvinnor till IT-branschen?

Hur kan vi attrahera fler kvinnor till IT-branschen?

Trots att många företag uttrycker en önskan om att stärka sina team med fler kvinnor, lyckas de inte alltid med detta mål. Det finns en mängd olika faktorer som bidrar till denna utmaning. Det kan handla om könsskillnader, beteenden, fördomar, och stereotypa uppfattningar. För att skapa en mer jämställd arbetsmiljö behöver företag ta itu med dessa hinder på flera fronter.

Fördomar och stereotyper

En av de största utmaningarna är de djupt rotade fördomarna och stereotyperna om kvinnor inom IT. Den traditionella bilden av IT-branschen som en manligt dominerad arena kan avskräcka kvinnor från att söka sig dit. För att bryta ner dessa barriärer måste företag aktivt arbeta med att förändra dessa uppfattningar både internt och externt.

Könsskillnader och beteenden

Forskning visar att det finns vissa könsskillnader i beteenden och preferenser som kan påverka kvinnors beslut att ge sig in i IT-branschen. Till exempel tenderar kvinnor att underskatta sina egna tekniska förmågor och kan därför avstå från att söka tekniska roller, även när de är kvalificerade. Företag behöver bli medvetna om dessa mönster och skapa en miljö som stödjer och uppmuntrar kvinnors självkänsla och självförtroende inom tekniska områden.

Strategier för att attrahera fler kvinnor till IT-branschen

För att övervinna dessa hinder och locka fler kvinnor till IT-branschen kan företag implementera en rad strategier:

Bekämpa fördomar och stereotyper internt
- Utbildning och medvetandegörande kring könsstereotyper och deras påverkan är avgörande. Genom att erbjuda utbildningar och workshops kan företag hjälpa sina anställda att känna igen och utmana sina egna fördomar.
Kvinnliga mentorer och förebilder
- Att ha kvinnliga mentorer och förebilder i företaget är viktigt. Dessa kvinnor kan agera som inspirationskällor och visa att framgång inom IT är möjlig för kvinnor. Mentorskap kan också ge stöd och vägledning till nya kvinnliga anställda.
Aktivt deltagande i kvinnliga nätverk
- Företag bör delta i och stödja kvinnliga nätverk och organisationer som Women in Tech, Pink Programming och Teknikkvinnor. Genom att vara aktiva i dessa nätverk visar företagen sitt engagemang för jämställdhet och skapar fler möjligheter för kvinnor att engagera sig i branschen.
Förändra företagskulturen
- En företagskultur som riktar sig till både män och kvinnor är avgörande. Detta innebär att eliminera machokulturen och skapa en inkluderande miljö där alla anställda känner sig välkomna och respekterade.
Rekrytering med medvetenhet om fördomar
- Rekryteringsprocesser måste utformas för att identifiera och minska fördomar. Detta kan inkludera anonymiserade ansökningsprocesser, mångfaldsutbildning för rekryterare och att säkerställa att intervjupaneler är diversifierade.

Tips till kvinnor som vill in i IT-branschen

För kvinnor som överväger en karriär inom IT är det viktigt att förstå att branschen inte är så komplicerad eller svårtillgänglig som den kan verka. Genom att våga ta steget och söka sig till tekniska roller kan kvinnor bidra till att förändra branschen inifrån. Det är också viktigt att söka stöd och nätverk som kan erbjuda mentorskap och inspiration.

För att attrahera fler kvinnor till IT-branschen behöver företag arbeta medvetet och strategiskt för att bekämpa fördomar, förändra företagskulturer och skapa stödjande nätverk och mentorskapsprogram. Genom att göra detta kan vi skapa en mer inkluderande och jämställd arbetsmiljö som gynnar alla.

Författare: Daria Rozanski, Account Manager på Developers Bay

Vill du veta mer om oss på Developers Bay?

De “mjuka” argumenten för att bli frilanskonsult jämfört med att vara anställd konsult

Sociala skillnader:

Säkerhet

○ Anställd konsult:

■ Det är många som hävdar att en anställning är tryggare än egenföretagande, men till exempel nu senast under Coronakrisen så var det fortfarande väldigt många som förlorade sina anställningar. Arbetsgivare är ofta företag som är vinstdrivande och de kommer självklart alltid att “se om sitt eget bo” först. Till syvende och sist är såklart den största tryggheten på arbetsmarknaden oavsett om du är anställd eller frilanskonsult alltid att ha attraktiv kompetens.

○ Frilanskonsult:

■ Frilanskonsultande är konjunkturkänsligt till viss del. Under Coronakrisen har jag pratat med frilanskonsultkollegor som vittnar om att deras uppdragsgivare försökt sänka deras ersättning, exempelvis. Vissa uppdragsgivare har försökt förhandla ett längre kontrakt mot en lägre ersättning och så vidare. Däremot ser jag det alltid som en möjlighet att gå tillbaka till en anställning eller helt förlita mig på min ekonomiska buffert i bolaget som jag har sparat ihop till. Det är desto svårare att gå från anställning till frilanskonsultande och på så vis finns det en inneboende trygghet för frilanskonsulter.

Det är helt enkelt så att du inte kan bli frilanskonsult om du inte kan bli anställd så du är redan attraktiv på arbetsmarknaden. Enbart genom att du har möjlighet att vara frilanskonsult bekräftar just det och det inger en trygghetskänsla i sig. Den ekonomiska bufferten är dock det viktigaste redskapet som jag har i min verktygslåda under lågkonjunkturer och på så vis har jag även fullständig kontroll och insyn i hur jag planerar för alla eventualiteter. Att du tjänar så pass mycket mer som frilanskonsult köper dig den trygghet du behöver, skulle jag vilja påstå. Motsvarande buffert är mycket dyrköpt som anställd. Det jag gillar mest med frilanskonsultandet är den fullständiga transparensen, att jag bara har mig själv att skylla och att jag vet exakt vad allting går till. Det är en oslagbar frihetskänsla!

Hemmahörande

○ Anställd konsult:

■ Jag har identifierat en trend, som jag dock tror är på nedåtgående framförallt i Corona-tider, men det är att arbetsgivare i allt större utsträckning försöker efterlikna vänskapskretsar. Ju starkare band mellan de anställda, desto svårare att sluta för den enskilda. Arbetsgivarna pratar om sin “starka, värdebaserade och unika kultur”. Arbetsgivaren spelar på folks känslor för du vill ju inte göra slut med dina vänner, eller hur?

Tidigare kände vi stark anknytning till exempelvis vårt grannskap på samma gata. Kan det vara så att arbetsgivaren är den nya knutpunkten nu när vi inte ens hälsar på våra grannar längre? En annan inlåsningseffekt är “sponsorskapet”, någonting som Sverige troligtvis har ärvt från den Amerikanska arbetsmarknaden. Mina kursare från KTH pratar om sina “sponsorer” på sina Amerikanska, men också svenska, arbetsplatser. Utan sin sponsor så finns det ingen som talar gott om en i “de viktiga sammanhangen”. Jag tycker att det är fruktansvärd setup som bara banar väg för “ass-licking”-kultur, falska löften och vassa armbågar. Den “hemmahörande”-känsla som många anställda känner tycker jag inte är riktigt sund eftersom den bidrar till en inlåsningseffekt som enbart arbetsgivaren drar nytta av.

Ju mer transparent arbetsmarknaden är och desto mindre inlåsningseffekter och trösklar, desto bättre för individen. Om dina kollegor verkligen är dina vänner så kommer du ju dessutom att behålla dem även om du eller de slutar (för annars är ni ju inte riktiga vänner). Som ni märker så värderar jag inte “hemmahörande” på en arbetsplats särskilt högt och om du gör det kanske inte frilanskonsult är ett bra upplägg för dig. Det du dock måste förstå är att alla teambuilding-aktiviteter, konferenser och liknande är pengar som du hade fått i egen ficka om du hade varit egen. Jag åker hellre med mina vänner eller familj på resa och bestämmer allting själv istället för att åka på konferens med en arbetsgivare, om jag fick välja. Arbetsgivaren är inte “schysst” som bjuder på konferens – det är pengar som de tar direkt från din lön.

○ Frilanskonsult:

■ Jag har dock aldrig känt mig så hemma som jag gör på mitt egna bolag, Roawr AB. Som frilanskonsult får jag en sund inställning till vad arbete faktiskt är – en transaktion – ett utbyte av pengar mot tjänster. Jag är upprörd över hur många mellanhänder som finns där ute och som försöker utnyttja det faktum att någon annan vill komma åt min kompetens. Ju mer friktionsfri transaktion desto bättre – för såväl mig som för uppdragsgivaren.

Långsiktig karriärbana och utveckling

○ Anställd konsult:

■ Som anställd får du coachning och du förväntas följa den löne- och karriärtrappa som så gott som alla IT-konsultbolag har satt upp. Om du vill avancera förväntas du inte bara börja coacha andra, utan även sälja andra konsulter och ta på dig personalansvar. Så småningom blir du partner (kanske efter 10 år) och då börjar du allt mer gå över till enbart sälj och/eller managing. Det finns ingen annan väg, skulle jag vilja påstå.

○ Frilanskonsult:

■ Många hävdar att de får utbildningar av sin arbetsgivare, men det kan du såklart köpa till dig själv i ditt egna bolag också. Det finns otroliga möjligheter med eget företag och med pengarna i företaget. Jag har exempelvis lärt mig ovärderliga företagsmässiga kunskaper, men också sparat ihop rejält med pengar i bolaget som köper såväl trygghet som frihet. Jag tog ledigt i 6 månader i somras med full lön och jag startar och leder egna initiativ på fritiden, så kallade egenprojekt, som exempelvis teamo.se. Jag hade varken haft pengarna, tiden eller företagsmässigheten för att starta och kunna driva sådana initiativ annars. Mitt långsiktiga mål är att sluta frilanskonsulta och gå över helt till att driva mina egna företag.

Samhälleligt ansvar

○ Anställd konsult:

■ Ingen kommentar.

○ Frilanskonsult:

■ Som frilanskonsult blir du tvungen att förstå och läsa på om hur allting fungerar. Jag känner mig genast mycket mer politiskt engagerad och hänger bättre med i debatter. Det är faktiskt fantastiskt intressant och lärorikt, för att inte säga roligt, att sätta sig in i bokförings-, skatte- och momsdjungeln och räkna på detta och diskutera med andra företagare.

Bemötande

○ Anställd konsult:

■ Generellt får du alltid viss annorlunda behandling som konsult och specifikt som frilanskonsult. Konsulter kan “ses lite ned på” i vissa kretsar och framförallt bland de anställda ibland på företag. Jag tror personligen att det grundar sig i ett slags avundsjuka.

○ Frilanskonsult:

■ Oftast är folk bara mer positiva och intresserade när du är frilanskonsult och egenföretagare jämfört med anställd konsult, enligt mina erfarenheter.

Här har jag som sagt försökt sammanfatta de “mjuka” skillnaderna mellan att vara frilanskonsult och anställd konsult. Läs gärna mer på min hemsida och hör av er till mig om ni har några frågor på pm@annaleijon.se

Lycka till i era karriärer oavsett vilken väg ni tar!

Anna Leijon, Frilansare och entreprenör

Vill du veta mer om oss på Developers Bay?

Analysis of AIOps – Guide For A Beginner

What is AIOps?

AIOps referred to as Artificial Intelligence for IT Operations is a term introduced by Gartner in 2016 relating to the category of Machine learning technology analytics which remediates Analytics of IT operations. Machine learning and big data are the 2 fundamental components of an AIOps system.

A comprehensive computational modeling and analytical approach is used to the integrated IT data to gather observational data and interactive data that can be obtained from a big data platform and necessitates a marked departure from sectionally segregated IT data.

Moreover, the objective is to facilitate IT development and obtain ongoing observations that, through automated processes, deliver ongoing corrections and advancements. According to this, AIOps can be thought of as CI/CD for essential IT operations.

Benefits of AIOps:

FASTER MEAN TIME TO RESOLUTION (MTTR):

AIOps can detect fundamental problems and provide alternatives more quickly and correctly than individuals are expected. This results in a shorter mean time to resolution (MTTR). This allows companies to establish and attain MTTR goals that were previously unheard of.

REDUCED OPERATIONAL COST:

Reduced operational costs will enable efficient utilization of resources through the automatic detection of operational risks and modified reaction routines.

Additionally, it liberates staffing resources to concentrate on more complicated and creative projects, enhancing employee engagement.

MORE OVSERVALIBITY AND BETTER COLLABORATION:

Available integrations within AIOps monitoring tools facilitate more effective cross-team collaboration across DevOps, ITOps, governance, and security functions. Better visibility, communication, and transparency allow these teams to improve decision-making and respond to issues more quickly.

ADAPT YOUR MANAGEMENT STYLE FROM REACTIVE TO PROACTIVE, TO PREDICTIVE:

AIOps constantly learns to recognize and prioritize the most essential warnings thanks to its integrated predictive analytics capabilities, enabling IT teams to solve prospective issues before they cause slowdowns or disruptions.

AIOps use cases:

Output data, aggregation, analytics, algorithms, automation and orchestration, machine learning, and visualization are just a few of the different AI techniques combined in AIOps. The majority of such techniques are fairly developed and well-defined.

Log files, metrics and monitoring tools, help desk ticketing systems, and other sources provide AIOps data. Every one of the technologies’ information is gathered and arranged into a suitable format using big data technologies.

There are a few reasons to use AIOps which are discussed below:

NOISE REDUCTION:

Analytics tools can analyze the unprocessed data to provide new data and metadata. In addition to seeing themes and relationships that allow the software to discover and locate errors, estimate capacity demand, and manage various happenings, analytics reduces noise, that is unnecessary or misleading data.

ROOT CAUSE ANALYSIS:

The process of root cause technique helps to analyze the source of an issue or flaw. Finding the underlying source of the issue or incident is the root cause analysis’s main goal. Understanding how to completely resolve, make up for, or take advantage of any systemic causes inside the biggest reason is the major priority.

ANOMALY DETECTION:

AIOps systems can sift through a dataset’s unusual data points by searching through a lot of previous data. These anomalies serve as “signals” that pinpoint and foretell hazardous occurrences, like data breaches.

ACTIVATION of DevOps:

DevOps accelerates growth by granting development teams greater authority to set up and modify infrastructure, but IT must still take care of that infrastructure. In addition, without requiring a bunch of extra administration work, AIOps gives IT the insight and analytics it requires to enable DevOps.

Moreover, the unnecessary cost outcomes like poor PR, penalties from the government, and a drop in customer satisfaction.

In conclusion, for all types of businesses, AIOps is unquestionably transformational. Not only to increase IT operational effectiveness, but also for business expansion.

Written by: Developers Bay

Vill du veta mer om oss på Developers Bay?

5 tips för att minska administration under ett konsultuppdrag

IT-konsult gör administrativt arbete vid datorn

5 tips för att minska administration under ett konsultuppdrag

Som konsult är tid din mest värdefulla tillgång. Ofta vill du kunna ha större flexibilitet, kanske jobba mindre, och framför allt: lägga din tid på arbete du faktiskt kan fakturera för. Att spendera mycket tid på administrativa uppgifter kan därför vara frustrerande och hindra dig från att fokusera på det du är bäst på: att ge värdefulla insikter och lösningar till dina klienter.

49% av soloprenörer spenderar mer än 16 timmar per månad på administration, och siffran är högre för de med aktiebolag. Det som är mest tidskrävande är kvitton och redovisning (Företagarindikatorn UNQUO & SEB 2021). UNQUO är en gratis app och tjänst för egenföretagare som underlättar och effektiviserar just ekonomi och admin, och på så sätt frigör både tid och energi till annat. För att du ska kunna minska tiden du lägger på administration – och få mer tid till det som är viktigt på riktigt – kommer här dessutom 5 tips, anpassade för dig som är konsult.

“49% av soloprenörer spenderar mer än 16 timmar per månad på administration, och siffran är högre för de med aktiebolag.”

Låt AI göra grovjobbet
AI:s framfart har nog ingen missat. Det finns redan idag många lösningar som är så bra att de kan göra hela arbetet åt dig, eller skapa ett bra underlag som sparar dig mycket tid. Ett exempel där AI kan effektivisera din tid, är gratis AI lösningar som hjälper dig förstå hur du ska bokföra dina utgifter som uppkommer under ditt konsultuppdrag. Andra exempel är att du kan få hjälp att skriva texter (även om de behöver korrigeras) och planera din tid.

Skapa standardiserade mallar för dokument
Förberedelse av rapporter, presentationer och andra dokument kan ta mycket tid om du börjar från noll varje gång. Skapa standardiserade mallar för dina dokument, inklusive rubriker, formatering och logotyper. På så sätt kan du snabbt anpassa dem till varje uppdrag och minska tiden du lägger på att skapa dokument från grunden. När du är på ett längre konsultuppdrag är dina administrativa uppgifter återkommande varje månad – både tidrapportering, utlägg och bokföring. Genom att skapa en mall första månaden kan du sedan återanvända den och endast göra små justeringar varje månad.

Få automatiska påminnelser
Med automatiska påminnelser om inbetalningar, tidsregistreringar osv så undviker du att uppgifter glöms bort, skapar merarbete eller ger dig straffavgifter. Genom att få påminnelser om uppgifter och aktiviteter kan du fokusera på det du gör just nu utan att oroa dig för att missa något viktigt. Det hjälper dig att förbättra din produktivitet och koncentration. Ett exempel på automatiska påminnelser som förenklar för dig är att få påminnelser för alla inbetalningar till Skatteverket. UNQUO har en funktion som kan ge dig påminnelser om alla viktiga datum som du behöver hålla koll på, anpassade efter just dig och ditt företag.

Använd digitala verktyg som hjälper dig
Att skapa och skicka fakturor, rapportera dina arbetade timmar och sköta utläggshantering kan vara en tidskrävande process. Du kan istället dra nytta av digitala verktyg och mjukvaror som automatiserar allt det här. Program som Bokio och Visma kan hjälpa dig att skapa och skicka fakturor snabbt och enkelt. För att förbereda dina utlägg inför bokföringen är en app ofta smidigast, eftersom du då kan du göra det på språng precis när behovet uppstår. UNQUO har en funktion där du kan fota kvitton, koppla dem till rätt transaktion, och sedan exportera allt direkt till ditt bokföringsprogram (eller skicka till din revisor).

“Gör det nu”-mindset
“Gör det nu” är ett populärt mindset ämnat för att minska stress och öka produktiviteten. Genom att anamma “gör det nu” när du är på konsultuppdrag kommer du att minska tiden du lägger på admin genom att det blir gjort direkt. Du kan släppa tankar och påminnelser om all admin du måste göra, och får istället mer tid och energi över till annat. Mindsetet är extra effektivt när det kommer till administrativa uppgifter som du kan göra på språng, som att till exempel fotografera och registrera utlägg direkt i UNQUO-appen. Att minska den tid och energi du lägger på administration är avgörande för att vara en effektiv konsult. Det är därför värt att lägga lite arbete på att genomföra dessa förändringar och få in de här processerna i din arbetsrutin, eftersom det i längden kan bidra till att maximera din produktivitet. Genom att använda digitala verktyg, standardiserade processer och smarta strategier kan du frigöra mer tid att leverera högkvalitativa konsulttjänster till dina klienter…eller till att vara ledig.

Förenkla din vardag direkt – ladda ned UNQUO-appen gratis här.

Författare: Anna Norén, Head of UNQUO

Vill du veta mer om oss på Developers Bay?

6 saker att hålla koll på i ett konsultavtal

6 saker att hålla koll på i ett konsultavtal

I vår roll så ser vi hundratals versioner av konsultavtal varje år. Det finns så klart många saker att vara uppmärksam på i ett avtal men nedan har vi sammanställt de sex punkter som vi tycker är extra viktigt:

Betalvillkor
Med detta menar vi inte bara att den ersättning man kommit överens om ska stämma utan även att man noterar hur lång tid Kunden har att betala fakturan. I vissa fall så har vi sett att Kunden har upp till 90 dagar på sig att betala. Detta innebär att du som Leverantör får vänta upp till 4 månader från påbörjat uppdrag innan du får din ersättning. Branschstandard brukar vara att betalning sker 30 dagar efter slutförd och fakturerad månad.

Uppsägningstid
I de flesta fall så har Kunden och Leverantören ömsesidig uppsägningstid. Den kan variera i längd (oftast mellan 1 och 2 månader) och gör det möjligt för båda parterna att avbryta samarbetet. Men detta är inte alltid självklart. I vissa fall har endast Kunden en uppsägningstid och därmed kan inte Leverantören säga upp avtalet. Det är dock väldigt sällan som Kunden tvingar en Leverantör att vara kvar en längre tid mot sin vilja men vi rekommenderar ändå alltid att lyfta denna punkt för att klargöra var Kunden står i frågan innan man signerar.

Ansvarsförsäkring
I alla avtal gällande Konsultuppdrag inom IT så bör det finnas en klausul gällande ansvarsförsäkring som Leverantören bör ha tecknat innan uppdragets start. Det varierar dock vilket belopp denna försäkring förväntas täcka. Branschstandard är cirka 10 miljoner och om Kunden begär att försäkringen täcker ett högre belopp så är det inte orimligt att fråga varför.

Konkurrensklausuler
Alla Kunder kommer begära att Konsulten som utför det enskilda uppdraget inte har ett parallellt uppdrag hos en konkurrerande aktör. Detta är fullt normalt. Men det är viktigt att noggrant granska konkurrensklausulers för att vara medveten om hur länge efter uppdraget detta gäller och ifall det även påverkar det AB som Konsulten är knuten till. Om man är oförsiktig med detta så riskerar man att, i onödig utsträckning, begränsa sina affärsmöjligheter.

Processen för eventuella förlängningar
Detta är något som kanske inte står i avtalet men ändå är väl värt att fråga kring. Olika Kunder har olika processer kring förlängningar det är viktigt att ha klarhet kring hur, och framför allt när, Kunden brukar förlänga sina konsultavtal. Detta kan variera ifrån att man har ett löpande avtal med 1 månads ömsesidig uppsägningstid (alltså inga förlängningar behövs) till att man förlänger en månad åt gången. Oavsett så är det bra att komma överens om parametrarna för hur långt innan ett befintligt avtal går som en dialog kring förlängning sker så att man inte riskerar missförstånd eller att man hamnar nära slutdatumet utan ett tydligt besked.

Definiera arbete på plats och / eller på distans i avtalet
Detta är viktigare än någonsin just nu, hösten 2021. Det är väldigt viktigt att definiera hur mycket man förväntas arbeta på plats i förhållande till distans i avtalet. Framför allt nu när det är så mycket oklarheter kring hur det kommer att se ut och risken för missförstånd och felaktiga förväntningar händer väldigt enkelt. Man kan så klart ha ett spann (t.ex 2-3 dagar på plats) men även det kommer ge en bra grund och säkerställa att alla är på samma blad kring den här högaktuella fråga.

Skribent: Lubomir Struwe, Sales Manager Sthlm på Developers Bay. Kontakt: lubomir@developersbay.se

Vill du veta mer om oss på Developers Bay?

Framgångsrika IT projekt

Framgångsrika IT projekt - Insikter och rekommendationer för en lyckad SaaS implementation

Jag avslutade nyligen ett större transformationsprojekt där vi på 12 månader implementerade två SaaS (Software as a Service) system; SAP lönesystem och Quinyx WFM system. Dessa hade både beroenden mellan sig och mot andra befintliga system i IT landskapet.

Implementationsprojektet föregicks av en strategistudie som kartlade verksamhetens långsiktiga behov samt en upphandlingsprocess (RFP) där behoven ställdes mot leverantörernas förmågor.

Vi uppfyllde våra mål med avseende på tid och kostnad samt kortsiktiga funktionella mål med implementationen. Det fanns så klart en del barnsjukdomar första månaderna men de långsiktiga verksamhetsmålen är inom räckhåll.

Innan det här projektet hade jag de senaste plus 4 åren jobbat i en annan bransch och främst med systemutveckling så det var ett tag sedan jag ansvarade för systemimplementationer. Här har jag samlat erfarenheter och rekommendationer för en lyckad systemimplementation.

1. Tydligt syfte – viktigt att man på förhand har klart för sig varför man genomför en oftast dyr investering. Hela styrgruppen och mottagande organisation måste vara införstådda med syftet som exempelvis kan vara:

i. Öka den operativa effektiviteten

ii. Minska kostnader

iii. Öka kundnytta eller nöjdhet

iv. Myndighetskrav

v. Öka konkurrensfördelar

Detta är viktigt för att det kommer att vara vägledande för olika beslut genomgående under projektets gång SAMT för effektuppföljning efter leverans.

2. Intressent involvering – engagera och involvera nyckelintressenter, inklusive chefer, avdelningschefer, slutanvändare och IT för att säkerställa att olika perspektiv och krav beaktas. Intressenter bör även involveras i planerings-, besluts- och utvärderingsstadierna av implementeringen för att främja inköp OCH ägande av det nya systemet. På så sätt känner samtliga intressenter ett ansvar för en lyckad implementation.

I min artikel om hur man lyckas med IT projekt har jag några praktiska tips på hur man identifierar och engagerar intressenter.

3. Robust kravhantering – dokumentera noggrant funktionskrav (vad systemet måste göra) och icke-funktionella krav (prestanda, säkerhet, skalbarhet etc.). Detta är avgörande för att välja rätt SaaS-lösning och utforma en effektiv implementeringsplan. Denna process innebär att genomföra intervjuer, workshops och undersökningar för att fånga intressenternas behov och preferenser. Samtliga krav måste med i RFP:n.

Obs att man alltid kommer på krav även under implementationen som man missat MEN ju noggrannare man är med RFP och upphandlingsprocessen desto mindre tjafs och konflikter under implementationen. Många leverantörer använder otydliga krav för att bättra sina marginaler med change requests (CR)

"Viktigt att man på förhand har klart för sig varför man genomför en oftast dyr investering"

4. Val av leverantör – val av rätt SaaS-leverantör är avgörande för att implementeringen ska lyckas. Faktorer att överväga inkluderar leverantörens rykte, meritlista, finansiella stabilitet, säkerhetsåtgärder, supporttjänster och inte minst passformen mellan deras lösning och din organisations krav.

Viktigt att begära demos för samtliga intressenter och på samtliga funktioner. Spela in demos! Gör referenskontroller då tidigare kunder har bra kännedom om produkten och leverantören. Utvärdering av servicenivåavtal (SLA) kan hjälpa till att fatta ett välgrundat beslut.

Börja med upphandlingen tidigt för att inte behöva stressa igenom implementationen. Ifrågasätt leverantörens leveransplan; är det en rimlig plan eller optimistisk? En för optimistisk plan kan vara ett knep från leverantören att bättra sina marginaler med CR

Viktigt att samtliga krav är tydligt definierade i avtalet. Involvera inköp och jurister som är proffs på avtal. Det spar mycket tid och möda längre fram i projektet.

5. Konfiguration eller anpassning – Att balansera anpassning, alltså att skräddarsy systemet efter specifika behov och konfiguration, alltså nyttja inbyggda funktioner och inställningar är avgörande för att optimera SaaS-lösningens funktionalitet, underhållbarhet och uppgraderingsbarhet.

Obs att även om anpassning kan vara lockande för att möta unika krav, kan det öka komplexiteten, kostnaden och beroendet av leverantören. Prioritera konfigurationen när det är möjligt för att förenkla implementering och löpande hantering!

Har du gjort rätt val av leverantör så har den oftast utvecklat systemet och dess processer efter ”best practice”. I de flesta fall är det enklare och bättre att anpassa interna processer efter det nya systemet. Tänkt efter noggrant innan du beställer specialanpassningar.

6. Datamigrering – Planering och genomförande av en smidig datamigreringsprocess är avgörande för att säkerställa att värdefull information överförs korrekt till det nya SaaS-systemet.

Detta innebär att identifiera datakällor (befintliga såväl som framtida), rensa och transformera data, kartlägga fält, testa migreringsskript och verifiera dataintegriteten efter migrering. Ett stegvis tillvägagångssätt och beredskapsplaner kan minska riskerna i samband med datamigrering.

7. Integrationer – Det nya systemet ska fungera i ditt befintliga IT -landskap. Att bedöma SaaS-lösningens integrationsförmåga är avgörande för sömlös anslutning till befintliga system och applikationer inom organisationens IT-ekosystem.

API:er (Application Programming Interfaces), webbtjänster och integrationsplattformar underlättar datautbyte och automatisering av arbetsflöden mellan olika system. Prioritera lösningar som erbjuder robusta integrationsmöjligheter och stödjer industristandarder.

Obs att om inte du har koll på ditt IT – ekosystem, saknar tydlig IT- strategi eller EA-tänk så blir det svårt att kravställa på leverantören

8. Förändringsledning och training – det är viktigt att tillhandahålla omfattande utbildning och stöd för förändringshanteringen för att säkerställa att användaren anpassar sig och minimera motståndet mot det nya SaaS-systemet.

Utbildningsprogram bör skräddarsys för olika användarroller, inlärningsstilar och kompetensnivåer.

Dessutom kan implementering av förändringshanteringsmetoder, såsom kommunikationsplaner, intressentengagemang och feedbackmekanismer från användare, underlätta en smidig övergång. Ett knep är exempelvis att involvera användare i både krav, upphandling och främst implementationen. Dessa är sedan ambassadörer i förändringsledningen. Går det att initialt rulla ut systemet lokalt som en pilot för att samla feedback och åtgärda barnsjukdomar så ökar det acceptans och minskar anpassningstiden

9. Resurser – Implementationsprojekt är resurskrävande, inte minst för förvaltande avdelning. Säkra tillräckligt med FTE:er för att inte slita ut personalen. Börja med rekryteringen tidigt då det kan ta tid att få in personal. Rådfråga med leverantörer hur mycket resursbehovet är. De är experter på det de gör.

Genomför själva styrning av projektet med extern personal och låt intern personal fokusera på praktisk implementation då det är den bästa utbildningen. Dessa måste ju sedan ta ansvar för förvaltning. Låt dem sedan genomföra utbildningen av slutanvändare.

Ta in en testledare tidigt i projektet. Testledarens roll, ansvar och leveransförmåga är avgörande för att lyckas med implementationen. Hen måste förstå kraven, verksamhetens behov och processer samt bli expert på systemet

Förvänta dig CR. Ju större leverantör desto mindre flexibilitet och fler CR. CR processer är tråkig och mycket tidskrävande. Säkra en dedikerad resurs som ansvarar för den, förhandlar och driver frågan i mål. Större leverantörer påbörjar inte jobb på CR förrän en överenskommelse är framtagen.

Ta inte in konsulter efter pris, det kommer att straffa sig i längden!

10. Feedbackmekanism och förbättringar – Uppmuntrande feedback från slutanvändare och intressenter hjälper till att identifiera användbarhetsproblem, funktionsförfrågningar och möjligheter till förbättringar i SaaS-systemet.

Implementera feedbackmekanismer som undersökningar, förslagsrutor, användarforum och helpdeskbiljetter för att samla in input från användare vid olika kontaktpunkter. Analysera feedbackdata regelbundet och prioritera förbättringar baserat på verksamhetens påverkan och användarbehov.

De bästa tipsen kommer paketerat i 10 men andra faktorer att tänka på är data och informationssäkerhet; support och förvaltningsorganisation; KPI:er och uppföljning av effektmål; cut-over och driftsättning; risk-, backup- och recoveryplaner

Genom att ta itu med dessa kritiska faktorer på ett systematiskt och proaktivt sätt kan organisationer öka sannolikheten för en framgångsrik SaaS-implementering och maximera värdet av deras investering i det nya systemet.

Hoppas dessa förslag och rekommendationer underlättar era implementationer. Ta gärna kontakt med mig om du vill diskutera och få praktiska tips på resp punkt.

Jag har tidigare skrivit en artikel på hur man lyckas med IT projekt som jag tycker du också ska läsa.

Författare: Bashtin Nematbakhsh

Om författaren:

Bashtin är en senior program- och projektledare med gedigen erfarenhet av att driva komplexa
projekt inom digitalisering och automatisering. Projekten har omfattat både IT systemutveckling, SaaS-lösning implementation, arkitektur, datahantering och verksamhetsutveckling.

Trots titeln brinner Bashtin för ett lean/ agilt förhållningssätt och använder sig gärna av agila arbetsmetoder i sitt ledarskap för att skapa flexibilitet, skalbarhet och kostnadseffektiva leveranser. Bashtin har en gedigen bakgrund som managementkonsult hos flertalet europeiska konsulthus
som exempelvis BearingPoint.

Vill du veta mer om oss på Developers Bay?

Så tänker du kring marknadsföring för din startup eller hobbyprojekt

Att starta företag som hobby- eller sidoprojekt och nå ut till potentiella kunder är svårt men det finns många aktiviteter inom marknadsföring att testa. I detta inlägg kommer Nils Fridlund som startade sin webbyrå, Sunbird, bredvid studier på Chalmers gå igenom vilka digitala marknadskanaler han rekommenderar i ett tidigt skede.

Inlägget utgår från att du har begränsat med tid, lite eller ingen tidigare erfarenheter av digital marknadsföring och att det inte finns någon större budget.

Första steget är en hemsida

För att jobba effektivt med digital marknadsföring behöver ni en hemsida.

Eftersom budgeten är begränsad kommer ni sannolikt inte kunna köpa exakt vilken hemsida ni vill.

Ni kan skapa en hemsida själv via en WordPress mall, WIX eller Squarespace.

Saknar ni IT-kunskaper helt och tycker allt med domäner och e-post känns skrämmande måste ni såklart ta hjälp med detta.

Det finns prisvärda lösningar såsom Fiverr och Freelancer där ni kan få in kunniga personer som vill skapa en portfolio.

Ett alternativ är självklart att köpa in en färdig hemsida av en webbyrå. Men många av de billigaste lösningarna blir inte bättre än det du gör själv.

Fördelen med att du driver skapandet av din egna hemsida är att du förstår din målgrupp och vad ni gör väldigt bra.

En hemsida kan man relativt snabbt byta. Men den grafiska profilen går inte lika snabbt att ändra då det finns ett upparbetat värde i den. Tipset är att lägga lite extra tid på den grafiska profilen och tonaliteten.

Summering:

Var noga med att skapa den grafiska profilen. Den kan vara med er länge eller för alltid.
Försök att skapa en första hemsida själv eller ta hjälp med delar. Har du en budget för hemsida kan du självklart köpa in detta.
En One Pager eller väldigt simpel hemsida är bättre till en början än ingen hemsida alls.

Den första kunden är den svåraste

Om det är ett hobbyprojekt eller startup så utgår jag från att ni inte har någon form av kapital att investera i bolaget.

Därför kommer den första kunden i allra högsta grad bistå med budget för att återinvestera i företaget.

Den första kunden är absolut svårast. Dels mentalt men också då ni saknar budget.

Jag fick in mina första kunder via familj och därefter vänner. Jag slet hårt för att göra dem nöjda då detta blev referenser till framtida potentiella kunder och gav viss betalning.

Kan ni inte använda befintligt nätverk får ni börja med organiska kanaler inom digital marknadsföring.

Organiska kanaler kan vara en väg

Mycket av den digitala marknadsföringen kräver budget då man betalar per klick till företag såsom Google eller Facebook.

Men det finns organiska kanaler där man inte betalar per klick, exempelvis sökmotoroptimering (SEO) och inlägg på sociala medier.

Det som kännetecknar båda dessa kanaler är att de brukar ta tid att nå framgång och att det kräver en del arbete under flera månaders tid innan man får genomslag.

Eftersom sociala medier är gratis och SEO kan göras på hemsidan du skapat kräver dessa inledningsvis bara tid och tålamod.

För att stå ut i bruset behöver ni på riktigt demonstrera kunskap. Ett konkreta exempel är att ni gör som följande:

Ni skriver hela inlägget på er hemsida (bra för SEO)
Ni postar en summering på sociala medier och länkar till inlägget (driver trafik till webbsidan)

Dessa kanaler är långsiktiga men är även för aktiva företag en bra källa för lönsam försäljning.

Efter att du fått in de första kunderna

När ni börjat få in kunder och kapital kan ni börja spendera mer.

Inledningsvis kan ni prova antingen Google Ads eller betald annonsering på sociala medier.

Vi rekommenderar Google Ads om det finns en tydlig definierbar tjänst som folk söker efter när de vill köpa.
Vi rekommenderar Facebook om det finns en tydlig målgrupp som ofta söker efter det ni erbjuder.

När trafiken ökat så pass mycket och ni har ett stadigt flöde med leads kan det vara värt att förbättra hemsidan.

En hemsida som säljer dåligt brukar vara en flaskhals för tillväxt och speglar varumärket därefter. Vår rekommendation är att kontakta en webbyrå som skräddarsyr hemsidor.

Skrivet av Nils Fridlund, grundare av Sunbird som är en webbyrå i Malmö. Nils har jobbat med skräddarsydda hemsidor i WordPress, SEO och Google Ads i över 10 år. Första åren som frilansare bredvid studier.

Vill du veta mer om oss på Developers Bay?

10 reflektioner om marknadsläget för frilansare inom IT just nu!

Vi har tagit oss tiden att reflektera över hur konsultmarknaden för frilansare inom tech faktiskt ser ut just nu samt vad som är de största utmaningarna och trenderna.

Här kommer 10 reflektioner baserat på våra egna erfarenheter och data från våra system:

1. Lönsamhet är fortsatt i fokus
Vi ser att färre personer förväntas göra mer, team managers får större team och man vill få ut mer effekt av färre resurser. Det görs färre nya satsningar och mer fokus läggs på core business där bevisad lönsamhet finns.

2. Myndigheterna verkar inte bli fredade 2024
Myndigheter tog in flest konsulter tidigare i år, men där ser vi en stor skillnad. Mindre anslag, nedskärningar och förändringar intern leder till minskat intag av konsulter.

3. Hög konkurrens på resursroller
Det är hög konkurrens bland react utvecklare, backend utvecklare och andra roller utan tydlig nisch. De mer generiska rollerna är otroligt konkurrensutsatta. Detta på grund av att beställarna har mycket att välja på. För att ge perspektiv på det så har vi ca 50-60 kandidater per uppdrag för dessa roller.

4. Nya uppdrag får pressade priser
Dom som sitter på sina uppdrag sedan 2021-2022 och blir förlängda har inte blivit utsatta för prispress märkbart medan de som ska ut på nya uppdrag nu upplever prispressning i större utsträckning. Skillnaden beror på att de som redan har varit på företaget en tid är insatta i rollen och bolaget och värderas högre pga. detta.

5. Fortsatt låg personalomsättning
De som är anställda är mindre benägna att testa marknaden och hitta nytt uppdrag. Finns färre uppdrag att välja mellan och anställda tenderar att sitta kvar. Det i sin tur öppnar upp för ännu färre lediga uppdrag

6. Rekrytering har visat sig bli svårt
Rekrytering har visat sig vara svårare för företagen än vad de först trodde. Man har underskattat det faktum att alla skulle ut och rekrytera, utan att alltid ha resurser och andra förutsättningar på plats för att hantera förväntningarna. Många kunder har därför tänkt om och börjat snegla på konsultlösningar vid befintliga behov.

7. Bank, försvar, energi och AI är starka områden
Dessa områden går fortsatt bra och är stabila då de får större budgetar och satsningar på ny teknik görs. AI är något som genererar nya satsningar och startups just nu och mycket pengar läggs där. Företag har dock svårt att veta VAD dom ska göra inom AI, det är en osäkerhet där man kan behöva vägledning. Inte självklart hur och vem som ansvarar för AI-kompetens hos företag. Därför blir det nödvändigt att ha en AI-strategi. Innovation och Greenfield trendar generellt. Många personer som blivit tvungna att lämna sina trygga anställningar får möjlighet att förverkliga sina drömmar och duktig kompetens finns tillgänglig för detta.

8. Punktinsatser / definierade projekt blir vanligare
Man ser på konsulter ur ett projektperspektiv snarare än en resurs. När man har begränsad budget så väljer man att investera i konsulter för precision. Man tar in topptalanger för specifika projekt.

9. Cloud / Infra / DevOps och Data Engineering är eftertraktade
Den typen av roller är svårare att rekrytera till eftersom att de inte är lika vanligt förekommande. Därför fortsatt högt eftertraktade. Även transformationsprojekt i legacy miljöer ser ut att bli konsult tungt då den kompetensen sällan finns inhouse och det finns ej tid att rekrytera. Dessa projekt är oftast tidskänsliga och det behöver gå fort.

10. Högre krav på konsulter
Definitionen av en senior konsult har förändrats, nu förväntas 10+ år snarare än 6-7 år. Beställarna kan ställa de kraven för att de faktiskt kan hitta kandidaterna just nu. En annan sak som vi märker är att beställare förväntar sig att konsulten även har affärsförståelse och inte bara teknisk kompetens. Kommunikation och kunskapsspridning blir också allt viktigare för kunden och att det finns ett bestående värde även efter avslutat uppdrag. Det är även värdefullt att själv kunna hitta behov i organisationen och sånt som kunden själv inte har tänkt på. En sådan sak kan vara avgörande för hur långt uppdraget blir.

Vi ser också att branschspecifik erfarenhet blir allt viktigare och det är viktigt att framhäva för att bli konkurrenskraftig vid intervju. Det kanske också vara en fördel att vara öppen för att återvända till tidigare kunder. Vi ser också högre krav på hybridlösningar som är 1-3 dagar på kontoret.

Vad kan man då göra och tänka på i en mer utmanande tid som frilansare inom IT?

Här kommer några av våra bästa tips:
Sticka ut med din kunskap – skapa mervärde
Se till att vara up-to-date
Ha tydlig bild hur du kan hjälpa kunden med konkreta exempel
Var konsultmässig då kraven ökar
Lösningsorienterad
Rådgivande
Förståelse för förutsättningar
Flexibilitet gällande remote arbete vs arbete på kontor
Anpassa CV:t till olika roller
Intervjuträning
Var flexibel med priset
Ha en tät dialog med din kund och förmedlare

Hoppas du fann dessa reflektioner och tips värdefulla. Du kan alltid kontakta oss på Developers Bay vid frågor!

Sammanställningen är gjort av Katarina Lind (konsultansvarig) och Lubomir Struwe (säljansvarig) på Developers Bay (december 2023).

Vill du veta mer om oss på Developers Bay?

How to pick an infrastructure as code language

You can use several languages today to define cloud infrastructure as code. Sometimes, you have a range of languages to choose from, even for a single tool.

So what language is the right choice? My intention with this article is to give you some guidance on how to pick the right language for you.

This text intentionally focuses on language choice, and not on tool features. You will still need to consider tool features, and I will briefly touch on some of these considerations, but not do a full-blown evaluation, since that would be a too large scope.

With that in mind, here are some aspects we will look at in terms of language choice:

Existing infrastructure code
Consider your target audience
Reduce cognitive load
Speed of feedback loop
Security considerations
Compliance and regulation requirements

Existing infrastructure code

If you inherit a lot of infrastructure already defined with some language and tool, it may be difficult to find business value to change this to something entirely new. This will need to be weighted in when choosing a language, and even more if choosing a new tool.

Do not just jump in headfirst to convert the code to something new. It is vital to understand the reasons behind the choices for the current language and tools. This is true for any non-trivial amount of infrastructure code.

I have myself been tempted on multiple occasions to switch to something I thought would be better. However, sometimes, I backed down from that after considering several points outlined below. In some other cases, we gradually changed, and that turned out to be a pretty good choice then.

If you have an infrastructure that is set up manually, aim to import that so you can manage these resources with infrastructure as code. You need to evaluate your tool choices and see what languages it will support to generate code for.

For retaining existing infrastructure as code, you will also need to consider the ability to integrate with other tool solutions:

CloudFormation and AWS CDK are in the same group of tools and integrate reasonably well. They do not integrate well with other tool groups (Terraform/CDKTF and Pulumi)
Terraform and CDKTF is in the same group of tools and has some (read) integration with CloudFormation, and thus indirectly with AWS CDK.
Pulumi has some (read) integrations with both Terraform and CloudFormation, and thus indirectly with AWS CDK and CDKTF

This is for integration with existing provisioned infrastructure, e.g. referencing resources in existing stacks or state storage. A more tool agnostic approach is possible as well. For example, by sharing resource references via AWS Systems Manager Parameter Store, then the underlying tools that provisioned a resource do not matter.

Consider your target audience

Who will define infrastructure? Are the application developers also responsible for the application infrastructure? Or is there a platform or operations team that handles the infrastructure?

Are there multiple groups, e.g. application developers handle “just enough infrastructure” and the more complicated parts by a platform team?

There may not be a single choice here, as the needs for each group to work efficiently with the infrastructure definitions may be different.

An application development team may work better with a different language than a platform team, since the way of working and tools used may be different.

Do not just jump in headfirst to convert the code to something new

Reduce cognitive load

Do you have an application development team that works with Java, and also will be responsible for application infrastructure? Then it may make sense to pick Java to define the infrastructure, as that may reduce the cognitive load – the amount of things you need to keep track of and handle to do the work.

If the application team does very little or no infrastructure, and a separate team handles the infrastructure which does not work with Java regularly, then a different choice may be better.

If an application development team handles some of the infrastructure, and another team the rest, then each team might benefit from different language choices.

When we talk about a cognitive load for different languages, it is not just the complexity of the language itself, but also the runtime environment and the surrounding tooling.

Which tools should we use for Python package management, virtual environments? What linters and test tools to use with Typescript, and what are the configuration settings for each of those? Are we using Gradle or Maven with Java? Should we runt terragrunt with terraform, and are we setting up tflint, tfsec or some other tools? Do we use Sceptre with CloudFormation?

If a language is not used daily, then the cognitive load may be significant each time you need to do something. In these cases, it is important to consider the languages themselves, the runtimes and the surrounding tools. Also, not just the happy day scenarios, but when things go wrong as well.

If you work with a certain language daily, then the additional cognitive load will not be that much, even if the language and tooling setup may be complex. You already manage that.

Note that reducing cognitive load does not mean you should always pick languages and ecosystems that a team already knows. If you expect the team to work with a language daily or with high frequency, it could be ok to use a new language and ecosystem. It is ok to learn something new, as long as you keep using it regularly.

Cognitive load and complexity of infrastructure

The cognitive load aspect load aspect may also come into play for the actual infrastructure definitions as well.

If you work on infrastructure that changes with about the same frequency as the application itself, then the added cognitive load may not be that high.

There may be infrastructure that does not change much, like virtual networks and VPN connections. Each time you actually need to change something here, there may be some additional cognitive load if you do not work with the networking daily. Thus, the life cycles of the infrastructure may affect the cognitive load.

What does this mean? It means static infrastructure that seldom changes benefit from languages that are easy to read and get into, even if you are not that familiar with the code. It also means that the language does not need to support complex logic, and a strictly declarative language may be just fine.

Infrastructure definitions which changes more often and may have more dynamic definitions, benefit from more expressive languages. The underlying representation can still be declarative.

In fact, many of the tools that support languages that are not strictly declarative, like AWS CDK, CDKTF, Pulumi and CDK8s, generate declarative definitions under the hood.

But for reading and understanding the infrastructure definitions, a declarative language may be better for static infrastructure, which does not need any complex logic to be defined.

Of course, supporting multiple languages may add complexity as well.

Cognitive load and package/module management

Most infrastructure-as-code tools have some sort of module/package management support, to handle re-use and defining suitable abstraction layers for the users of a module/package.

Using those is part of the expected for each language choice. However, if you decide to support multiple languages with packages, then you will add cognitive load for the package maintainers.

For example, if you want to support Typescript, you typically need to deal with npm, with Python you deal with PyPi, Java you use Maven, C# you use NuGet, etc.

Cognitive load and (idiomatic) language use

If a tool support multiple languages, that means there are some restrictions on packages and/or code to work with all supported languages.

That can also be more apparent if you pick a language that may not be officially supported or have first class support, but have a supported runtime – such as the JVM or .NET runtimes.

Any such deviations might add to the cognitive load as well. Of course, the extent to which a language is used with the specific tool choice is a consideration as well. How easy is it to get help and find examples for a particular language?

Cognitive load across tools

Mixing multiple tool and tool families is certainly possible, but may add cognitive load as well, regardless of language. It is somewhat fuzzy at times.

CloudFormation and AWS CDK is in the same family in that the underlying representation used is CloudFormation, although AWS CDK introduces a few new concepts in the mix
Terraform and CDKTF in the same family in that the underlying representation used is Terraform, although there are a few new concepts with CDKTF also.
All CDK tools (AWS CDK, CDKTF, CDK8s) share some common elements as well
There are some similarities across all tools that use programming languages as well, including most of the supported languages
Both CDKTF and Pulumi have some support to use AWS CDK components in the code

Speed of feedback loop

It is slow to provide infrastructure, much slower than just starting an application most times. This is something to keep in mind.

Mostly, the speed of the language execution itself is not a bit factor. It is often more about the speed of the tool itself rather than the language used.

I did some experiments with AWS CDK and the time to generate the underlying CloudFormation was about the same regardless if I used Go, Typescript or Python for example.

Since there is an extra step to generate CloudFormation, or Terraform with CDKTF, there is some extra time added compared to using CloudFormation or Terraform directly. The extra time here may not be a good enough reason to avoid it.

Good type checking and tooling support in IDEs or editors can shorten feedback loop, if that exists for a language. This is typically an advantage for many regular programming languages.

Security considerations

Is the use of a particular language, its runtime and associated tooling secure? More versatile languages and tooling comes with additional risks to expose the infrastructure definitions to troublesome pieces of code.

How trustworthy are any imported packages/modules and are they locked to a specific release? Do you require fetching data from outside to import when you build your infrastructure?

What packages should be safe to import and use? Should there be guidelines and checks for how a specific language is used and what can be imported?

Again, the language runtime and the surrounding ecosystem are important to review and decide on safe usage patterns.

Compliance and regulation requirements

Your line of business may have compliance requirements that will affect language and language ecosystem choices. This is something to look at, in particular if you are introducing an entirely new language and ecosystem to the business.

Any issues are more likely around the ecosystem and tooling and practices around these than the language itself.

This also includes any potential licensing issues, although this is more likely to be a potential issue for any specific tooling or 3rd party packages used than for the language itself. Again, this may require some extra effort in particular if you are introducing a new language and ecosystem to the business.

An example

Setting

Let us take a fictional example. The company myexample.com has about a dozen development teams and a platform team. There are multiple solutions and services these teams work on. Some services are built with Typescript, others are built with Go.

Each development team handles infrastructure close to the application solution, e.g. services as AWS Lambda, DynamoDB, ECS Fargate, etc. They have separate accounts for development, test and production in most cases, although some environments have shared networking as well.

Networking setup, IAM, backups and baseline security setup are handled by the platform team, and they also have a mix of people that work with the infrastructure setup daily, as well as more seldom.

Teams use a mix of Serverless framework, CloudFormation and a bit of AWS CDK for their infrastructure and application deployment. There are also resources that have been set up manually. For AWS CDK, there are infrastructure resources set up in Typescript and Python.

Some teams have automated deployments, some have manual deployments.

Choice example

Since development teams work daily with Typescript and Go, it makes sense that those that use AWS CDK with Typescript can continue with that. It may make sense to use Go also for team infrastructure, if there are teams that use Go daily, but not Typescript.

Right now AWS CDK with Python may be an outlier, and potentially drop that and look at converting to Go or Typescript.

Platform team may benefit from having relatively static infrastructure in a more declarative format, e.g. CloudFormation YAML, Terraform HCL, or Pulumi YAML (or CUE). When a programming language would be used, one of Typescript or Go would be likely candidates. Go’s ecosystem and tools may be simpler to grasp and keep control of, and fewer 3rd party dependencies. But this would also depend on other tasks that the platform team is doing.

Technically AWS CDK, CDKTF and Pulumi all support Go and Typescript. If the platform team would build re-usable components or modules for the other teams, they would need to support multiple languages. For AWS CDK, that would mean in practice to write these components/modules in Typescript – or CloudFormation with some Typescript. It could be in HCL with some typescript or all in typescript. For Pulumi it should be possible with any of the languages.

I have avoided picking any specific tools here, since there would be a need to more in depth on the situation at myexample.com.

Summary

In this article I have tried to point to some considerations when picking a language for infrastructure as code, without going into much specifics for each tool.

Most of the text deals with cognitive load, which I think most times is not fully appreciated for the intended target audience of the infrastructure definition work.

One tool or language does not fit all, and sometimes it may be better to have a limited selection rather than a single choice, or a total free-for-all.

For example, I have worked with a few projects where AWS CDK using Typescript has been the tool and the language of choice for everyone. Sometimes that worked reasonably well, in others it did not work out. The threshold to work with the language and ecosystem, as well as the underlying tools, were too high for some people, and the maintenance suffered because of that.

Do you have any experiences yourself with language choices for infrastructure-as-code? What are your thoughts?