Software development is one of the professions where you have to keep your knowledge up to date and follow what happens in the field. Staying current and expanding your horizons can be achieved in different ways and one good way I have used is to follow different news sources, newsletters, listening to podcasts and attending meetups. Here is my opinionated selection of resources to learn, share ideas, newsletters, meetups and other things for software developers.


There are some good news sites to follow what happens in technology. They provide community-powered links and discussions.


Podcasts provide a nice resource for gathering experiences and new information about how things can be done and what’s happening and coming up in software development. I commute daily for about an hour and time flies when you find good episodes to listen to. Here’s my selection of podcast relating to software development.


Software Engineering Daily: ”The world through the lens of software” (available i.a. on iTunes)
Software Engineering Radio: ”Targeted at the professional software developer. The goal is to be a lasting educational resource, not a newscast”. (feed)
ShopTalk: ”An internet radio show about the internet starring Dave Rupert and Chris Coyier.” (available i.a. on iTunes)
Full Stack Radio: ”Every episode, Adam Wathan is joined by a guest to talk about everything from product design and user experience to unit testing and system administration.” (feed)


Syntax: ”A Tasty Treats Podcast for Web Developers.” (available i.a. on iTunes)
The Changelog: ”Conversations with hackers, leaders, and innovators of software development.” (available i.a. on iTunes)
React Podcast: ”Conversations about React with your favourite developers.” (available i.a. on iTunes)
Brainfork: ”A podcast about mental health & tech”


React Native Radio as a podcast (available i.a. on iTunes)

In Finnish

ATK-hetki: ”Vesa Vänskä ja Antti Akonniemi keskustelevat teknologiasta, bisneksestä ja itsensä kehittämisestä.” (available i.a. on iTunes)
Webbidevaus: ”Puheradiota webbikehityksestä suomeksi! Juontajina Antti Mattila ja Riku Rouvila.” (available i.a. on iTunes)


Normal information overload is easily achieved so it’s beneficial to use for example curated newsletters for the subjects which intersect the stack you’re using and topics you’re interested at.
The power of a newsletter lies in the fact that it can deliver condensed and digestible content which is harder to achieve with other good news sources like feed subscriptions and Twitter. A well-curated newsletter to a targeted audience is a pleasure to read and even if you forgot to check your newsletter folder, you can always get back to them later.


Hacker Newsletter: Weekly newsletter of the best articles in Hacker News.

Mobile development

iOS Dev Weekly: Hand-picked round up of the best iOS development links published every Friday.
This Week In Swift: List of the best Swift resources of the week.
iOS Dev nuggets: Short iOS app development nugget every Friday/Saturday. Short and usually something you can read in a few minutes and improve your skills at iOS app development.
React Native: Bi-monthly summary of React Native news, articles, issues & pull requests, libraries and apps.


Java Web Weekly by Baeldung: Once-weekly email roundup of Java Web curated news by Eugen Baeldung.
The Java Specialists’ Newsletter: A monthly newsletter exploring the intricacies and depths of Java, curated Dr. Heinz Kabutz.
Java Performance Tuning News: A monthly newsletter focusing on Java performance issues, including the latest tips, articles, and news about Java Performance. Curated by Jack Shirazi and Kirk Pepperdine.


DB Weekly: A weekly round-up of database technology news and articles covering new developments, SQL, NoSQL, document databases, graph databases, and more.


HTML5Weekly: Weekly HTML5 and Web Platform technology roundup. Curated by Peter Cooper.
CSS Weekly: A roundup of css articles, tutorials, experiments and tools. Curated by Zoran Jambor.

Web development

Status code: ”Keeping developers informed.” weekly email newsletters on a range of programming niches (links to JavaScript weekly, DevOps weekly etc.)
Web Development Reading List: Weekly roundup of web development–related sources, selected by Anselm Hannemann.
Hacking UI: A weekly email with our favourite articles about design, front-end development, technology, startups, productivity and the occasional inspirational life lesson.
Scott Hanselman: Newsletter of Wonderful Things. Includes interesting and useful stuff Scott has found over the last few weeks and other wonderful things.
MergeLinks: Weekly email of curated links to articles, resources, freebies and inspiration for web designers and developers.
“How to keep up to date on Front-End Technologies” page lists newsletters, blogs and people to follow.


JavaScript Weekly: Weekly e-mail round-up of JavaScript news and articles. Curated by Peter Cooper.
Node Weekly: Once–weekly e-mail round-up of Node.js news and articles.
A Drip of JavaScript: “One quick JavaScript tip”, delivered every other Tuesday and written by Joshua Clanton.
SuperHero.js: Collection of the best articles, videos, and presentations on creating, testing, and maintaining a JavaScript code base.
State of JS: Results of yearly JavaScript surveys

User experience and design

UX Design Weekly: Hand-picked list of the best user experience design links every week. Curated by Kenny Chen & published every Monday. To satisfy your web aesthetics with a list of the 5 best design links of the day. The content is manually curated by a couple great editors.
Userfocus: Monthly newsletter which shares an in-depth article on user experience.


DevOps Weekly: Weekly slice of devops news.
Web Operations Weekly: Weekly newsletter on Web operations, infrastructure, performance, and tooling, from the browser down to the metal.
Microservice Weekly: A hand-curated weekly newsletter with the best articles on microservices.


You can learn much from others and to broaden your horizon it’s beneficial to attend different meetups and listen to how others have done things and watch war stories. Also free food and drink.

Mostly Helsinki based

Tampere (Finland) based

Community chats

Feel free to add your favourite resources in the comments below.

Marko Wallin

Marko Wallin työskentelee ohjelmistosuunnittelijana Goforella ja muuttaa maailmaa paremmaksi digitalisaation keinoin. Hänellä on vuosien kokemus ohjelmistokehityksestä, ketteristä menetelmistä ja ohjelmoinnista sekä käyttöliittymän, taustapalveluiden että tietokantojen osalta. Vapaa-ajallaan Marko jakaa teknistä osaamistaan blogiensa kautta ja kehittämällä muun muassa avoimen lähdekoodin mobiilisovelluksia. Sovelluskehityksen lisäksi hän harrastaa maastopyöräilyä.

Piditkö lukemastasi? Jaa se myös muille.

Choosing React Native in 2019

As a head of mobile development, part of my role is to evaluate technologies in order for us to know what are the strengths and weaknesses of the said technology. This will inform us what we should use when a new project is starting up.
Gofore has used React Native extensively for the past two years. We have had success with it and enjoy using it. It is definitely possible to make real production grade apps, as an example, the Google play store Best of 2018 app was made using React Native. Still, there is room for improvement to be able to declare React Native 1.0 stable and ready. During 2018 there was some turbulence and uncertainty regarding the future of React Native. It made me begin closely following the future of the library. Here is a report of my findings.
TL;DR: It is looking like 2019 will be the year of React Native coming of age. There are many ongoing undertakings to make React Native even better than it is today. I am more excited for the future of React Native than I have ever been. Here are some of the (technical) reasons why.

Facebook contributions

React Native was created by Facebook and for a while, in 2018 it was a bit unclear how much Facebook was investing in the technology. After some rumours, Facebook made it clear through words and actions, that they are in it for the long haul.
One good sign that Facebook is ramping up work on React Native is the fact that they have been hiring more developers to their React Native team.
Firstly, React Native will enjoy improvements in React itself, which will have two big new features added in 2019: Hooks and Suspense. Hooks will let developers use state and other React features in functional components. After trying out hooks, I have been eagerly waiting to be able to use them everywhere! Suspense refers to Reacts new ability to “suspend” rendering while components are waiting for something and display a loading indicator. This will ease the typical pain point of having to figure out different states (init, loading, error, ready) for your component. Suspense will manage the complexity for you.
In June, Facebook published a blog post explaining that they are “working on a large-scale re-architecture of React Native to make the framework more flexible and integrate better with native infrastructure in hybrid JavaScript/native apps.”
This rework includes a JavaScript interface (JSI),UI re-architecture (called Fabric) and the new native module system (called TurboModules) but is generally referred to altogether as Fabric. This will offer significant improvements under the hood. It will also improve performance, simplify interoperability with other libraries, and set a strong foundation for the future of React Native.
In November Facebook published a roadmap for React Native. It gives an outline of their vision, including a healthy GitHub repository, stable APIs, a vibrant ecosystem and excellent documentation.
These are all areas where React Native has been criticized and I am really excited to see that Facebook has identified them and is actively working on improvements. It will lay a good foundation for the open source community to participate and contribute.

Open source community

React Native open source community got way more organized in 2018 and it seems we will reap the rewards of that in 2019. There is a new repository for transparent discussions and proposals, which facilitates changes proposed and made by the open source community.
There is an ongoing project called The Slimmening, which aims to make React Native core smaller, extracting parts of it that can be more easily maintained and developed separately. There are already two good examples of this. Jamon Holmgren (@jamonholmgren) championed extracting Webview and Mike Grabowski (@grabbou) spearheaded efforts to extract React Native CLI. Webview has already received much more love as a standalone library and it shows the potential of what The Slimmening, once done, can mean for the future of React Native.
Another ongoing project, which should be close to being finished, is updating Android JSC (which is used to run the Javascript on Android). The current version is archaic and results in differences between iOS and Android and performance issues. Having a modern runtime is crucial for the promise of a truly cross-platform development environment. Upgrading the JSC would greatly improve the performance of react native apps running on Android and allow support for x64 builds on Android apps.
Currently, there are a lot of 3rd party community libraries. The typical challenge with them is that they might not be well maintained. Expo is a company building on top of React Native. They have been pushing to be able to do React Native development without having to have knowledge of the native parts. Expo APIs look well thought of and maintained, but they have not been available out of the Expo React Native project. That is, until now. Having well-maintained community APIs available will make a significant difference for developers.


Hopefully, this list of ongoing technical projects and improvements in and around React Native has given you some insight into the potential that React Native has. Time will tell how well it delivers, but as of now, I am very positive and excited to be a mobile developer using React Native. I will be recommending React Native for many mobile projects at Gofore in the future as well. Let me know your thoughts in the comments below.

Juha Linnanen

Head of Mobile Development at Gofore Helsinki. Passionate about creating mobile applications that help achieve results.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Ohjelmistoprojektit ajavat usein karille, koska ne eivät saa riittävää tukea kehitystiimin ulkopuolelta. Tämän vuoksi on hyvä palauttaa mieliin, että tietojärjestelmäprojektia ohjataan aktiivisesti kehitystiimin ulkopuolella. Yleisesti käytetyssä Scrum-prosessissa tämä rooli kulkee nimellä tuoteomistaja. Tuoteomistajan vastuulla on maksimoida tiimin sidosryhmille ja käyttäjille tuottama lisäarvo.
Tuoteomistajan tulee ymmärtää loppukäyttäjiä, markkinaympäristöä, kilpailua ja toimialan tulevaisuuden trendejä. Käytännössä henkilö onkin usein esimerkiksi joku kohdeorganisaation tuotehallinnosta tai markkinoinnista. Muuttujia on kuitenkin paljon sen mukaan, kehitetäänkö kaupallista vai sisäistä ohjelmistoa tai laitetta.
Tuoteomistajalla tulee olla kyky abstraktiin ajatteluun, jonka avulla hän kykenee kuvaamaan ylätason vision, ja muokkaamaan käyttäjien ja markkinoinnin vaatimukset toteutuksen lähestyessä myös yksityiskohtaisiksi käyttötapauksiksi. Tuoteomistajan tulee olla taitava kommunikoija, jotta hän pystyy toimimaan tehokkaasti tässä käyttäjien ja kehitystiimin muodostamassa paineessa.
Tuoteomistajan avaintehtäviä ovat priorisointi, tavoitteiden tarkentaminen ja kehityksen mittarointi.

KUVA 1: Tuoteomistajan ydintehtävät.


Priorisointi on yksi tuotekehityksen kriittisimpiä vaiheita. Tekemistä on aina enemmän kuin aikaa tai resursseja. Tämän vuoksi on tärkeää listata, analysoida ja pisteyttää tekemättömät asiat siten, että ne voi tunteettomasti laittaa paremmuusjärjestykseen. Pitää varmistua, että tehdään sekä asioita oikein että oikeita asioita. Yksi tuoteomistajan avaintehtävistä on päättää, mihin lähitulevaisuuden resurssit suunnataan, eli mihin asiakasryhmään, toiminnallisuuteen tai ongelmakenttään keskitytään. Tässä voi käyttää apuna Lean Startup -ajattelun 2×2-priorisointimatriisia.

KUVA 2: Lean Startup priorisointi -matriisi, joka auttaa järjestämään tehtävät niiden tuottaman lisäarvon ja vaatiman työmäärän perusteella.
Työmääräarvion tekeminen jää kehitystiimin harteille. Tämän vuoksi tuoteomistajan on hyvä käydä työjonoa läpi yhdessä kehitystiimin kanssa säännöllisesti ja pyrkiä tarkentamaan, pilkkomaan sekä arvioimaan työjonossa olevia käyttötapauksia.
Käyttötapausten lisäarvon arvioiminen on puolestaan tuoteomistajan tehtävä. Lisäarvon arvioimisessa voi pohtia esimerkiksi seuraavia asioita:

  • Kuinka suureen osaan käyttäjiä käyttötapaus vaikuttaa?
  • Auttaako käyttötapaus saamaan uusia käyttäjiä?
  • Auttaako käyttötapaus saavuttamaan rahallista voittoa joko säästöjen tai tulojen muodossa?
  • Tehostaako käyttötapaus oman organisaation tai muiden loppukäyttäjien toimintaa?
  • Auttaako käyttötapaus maineen kasvattamisessa ja brändin kehittymisessä?

Tarkenna ja kirkasta

Tuoteomistajalla viitataan henkilöön, jolla on visio siitä, mitä ollaan tekemässä. Tuoteomistaja omistaa siis vision siitä, mitä ollaan rakentamassa. Scrum-tiimi auttaa tuoteomistajaa jäsentelemään, pilkkomaan ja vaiheittain toteuttamaan vision mukaisen toiminnallisen kokonaisuuden.

KUVA 3: Tuoteomistaja omistaa vision tavoitteesta ja pyrkii parhaan kykynsä mukaan ohjaamaan Scrum-tiimiä tavoitetta kohti.
Tuoteomistajan pääasiallinen työkalu on työjono, johon hän tiimin avustuksella jäsentelee yksityiskohtaisempaa kuvausta seuraavaksi toteutettavaksi priorisoiduista ominaisuuksista. Tuoteomistaja määrää Scrum-tiimin suunnan, ja tiimi itse määrää nopeuden.
Hyvä käytäntö on, että työjonon yläpäässä on Scrum-tiimille yksityiskohtaisesti kuvattuja käyttötapauksia seuraavien 2 – 3 sprintin ajaksi. Scrum-tiimi itse kuitenkin valitsee, kuinka paljon työjonon yläpään ominaisuuksia he katsovat ehtivänsä toteuttaa seuraavan sprintin aikana. Tästä muodostuu Scrum-prosessin kadenssi, jossa tiimi sitoutuu toteuttamaan tietyn työpaketin sprintin aikana. Samalla tuoteomistaja sitoutuu olemaan häiritsemättä tiimiä muilla, kuin sprintin työjonoon valituilla ominaisuuksilla sprintin aikana.

KUVA 4: Työjonossa eniten arvoa tuottavat ja lyhyimmät tehtävät priorisoidaan korkeimmalle, koska ne tuottavat eniten lisäarvoa pienimmällä vaivalla. Kuvan työjonoon on priorisoitu ja arvotettu ominaisuuksia kahden sprintin verran, mutta viimeinen käyttötapaus tulee vielä tarkentaa ja pilkkoa pienemmäksi, jos se halutaan saada mukaan toiseen sprinttiin.
Tuoteomistaja auttaa tiimiä rakentamaan oikeanlaisen tuotteen. Tiimi toteuttaa käyttötapauksia parhaan tietämyksensä ja ymmärryksensä mukaisesti, mutta tuoteomistaja tulkitsee sidosryhmien avustuksella, ovatko ominaisuudet sellaisia, kuin haluttiin. Tuoteomistaja antaa kehitystiimille palautetta sekä siitä mitä rakennetaan, että miten rakennetaan. On tärkeää, että tuoteomistaja ottaa ylätasolla kantaa myös miten-osioon, eli vaatii työmäärän ja kapasiteetin arviointia, toteutuneen kapasiteetin mittarointia sekä CI-järjestelmän ja automaattisten testien käyttöönottoa.
Tuoteomistajan tulee pyrkiä kiihdyttämään palauteluuppia. Kun tuoteomistaja vaatii säännöllisiä ja aikaisia tuotejulkaisuja testiympäristöön, on hänellä mahdollisuus demonstroida tuotetta aikaisessa vaiheessa sidosryhmille ja näin kerätä arvokasta palautetta siitä, onko tiimi menossa oikeaan suuntaan.


Tuoteomistaja johtaa sekä tiimiä että itseään. Tuoteomistaja työskentelee tiiviisti sidosryhmien kanssa määritellen ja tarkentaen tiekarttaa. Tuoteomistaja määrittelee ja hallitsee tiimien lyhyen aikavälin työjonoja ja varmistaa, että tiimit liikkuvat samaan suuntaan sekä suhteessa toisiinsa että suhteessa pitkän aikavälin visioon. Tuoteomistaja on kehitystiimeille asiakasorganisaation toiminnallinen asiantuntija ja toisaalta tuotekehitysasiantuntija oman organisaationsa suuntaan.

KUVA 5: Scrum-prosessissa tuoteomistajan tärkeimmät tapahtumat ovat sprintin suunnittelu, työjonon tarkentaminen ja priorisointi, sekä sprintin demo ja seuraavan sprintin suunnittelu.
Tuoteomistaja pyrkii sivistämään Scrum-tiimiä suunnittelupalavereissa tuotteeseen liittyvästä bisneksestä, ja hyödyntää keskusteluita mahdollisuutena reflektoida tehtyä ja tulevaa. Tähän kyetäkseen tuoteomistajan tulee ymmärtää sekä asiakasryhmiä ja loppukäyttäjiä, että laajempaa toimintaympäristöä ja markkinoita.
Lopulta tuoteomistaja on henkilö, joka on vastuussa johdolle ja organisaatiolle siitä, että Scrum-tiimi tuottaa organisaatiolle mahdollisimman paljon lisäarvoa. Hyvä käytäntö onkin raportoida muulle organisaatiolle säännöllisesti projektin etenemisestä esimerkiksi sprinttiraportilla, tuoteblogilla tai sisäisillä tuotedemoilla, jolloin pystytään sitouttamaan muutakin organisaatiota yhteiseen tuotekehitysponnistukseen.
Toisinaan asiakasorganisaatio ja sidosryhmät ovat hyvin argressiivia ja nälkäisiä näkemään mahdollisimman nopeasti omia vaatimuksiaan tuotteessa. Tällöin tuoteomistajan tulee käyttää aktiivisesti energiaa odotusten hallintaan, eli kertoa bisnesomistajille, mitä projektissa saavutetaan ja millä aikajänteellä. Toisin sanoen tuoteomistajan tulee kyetä sanomaan kaikkiin epärealistisiin ominaisuus- ja aikataulutoiveisiin jämerästi ”ei”. Bisnesomistajat voivat toisinaan olla hyvinkin päättäväisiä toiveissaan saada oma kädenjälkensä näkyville tuotteessa, jolloin tuoteomistajalta vaaditaan paksua nahkaa ja lehmän hermoja projektivision mukaisen suunnan säilyttämisessä ja pitkäjänteisessä priorisoinnissa.

KUVA 6: Tuoteomistaja suojaa ytimessä olevaa Scrum-tiimiä asiakasorganisaation bisnesihmisten ja avainkäyttäjien aiheuttamalta kohinalta.

Tuoteomistajan yleisimmät ongelmat

Scrum-tiimin näkökulmasta yleisimmät tuoteomistajan kanssa nähtävät ongelmat ovat seuraavat:

  • Poissa vahvuudesta (missing in action) kuvaa tuoteomistajaa, joka ei sitoudu Scrum-prosessin mukaisiin tapaamisiin tai tehtäviin.
  • Siipirikko (lame duck), jolla ei ole valtaa, kykyä tai osaamista tehdä vaadittavia päätöksiä. Tuoteomistajan tulisi kyetä aina tarjoamaan vastaus Scrum-tiimin tuotevisiota tai tuotteen työjonoa koskeviin kysymyksiin.

Molemmissa tapauksissa tuoteomistaja joko hidastaa projektin etenemistä tai antaa projektin edetä useamman sprintin väärään suuntaan. Lue lisää Goforen blogista The Best Ways to Screw Up an Agile Project.

KUVA 8: Tuoteomistajan yleisimmät ongelmat.
Tuoteomistajan tulee siis resursoida riittävästi aikaa ja energiaa Scrum-tiimin tukemiseen. Tuoteomistajan tulee aktiivisesti edistää ja kommunikoida projektistaan kotiorganisaatiossaan sekä luonnollisesti osallistua aktiivisesti Scrum-prosessin avaintapahtumiin.

Tuoteomistajan avaintehtävät

  1. Työskentele tiiviisti sidosryhmien kanssa tarkentaen ja kirkastaen pitkän aikavälin tiekarttaa.
  2. Priorisoi lyhyen aikavälin työjonoa ja varmista, että tiimi liikkuu oikeaan suuntaan suhteessa pitkän aikavälin visioon.
  3. Toimi tiimille päin asiakasorganisaation toiminnallisena asiantuntijana.
  4. Toimi asiakasorganisaatiolle päin tuotekehitysasiantuntijana.

On siis tärkeää muistaa, että tuoteomistaja on vastuussa tuotekehitysprojektin ROI:sta. Tiimi vastaa teknisistä valinnoista, Scrum Master kutittelee tiimistä parhaat mahdolliset tehot ja tuoteomistaja takaa, että tiimi tekee oikeita asioita oikeaan aikaan.

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Where GCP and AWS are like two peas in a pod, Azure is something different.  Azure has taken much of the things that can be found in more traditional Microsoft infrastructure and taken it to the cloud. Also, much thought has been given to the idea that cloud should work as an extension to that on-prem-Microsoft-infra. In recent times Azure has taken steps towards becoming more like its competitors; it has dropped pretty much every other container orchestration service other than Kubernetes and is slowly adopting Availability Zones (for example).
Use cases for Azure are mostly those projects that go heavy on Visual Studio, AzureAD or to be paired with existing on-prem-MS-infra. Out of the cloud offerings, Azure is my least favourite, maybe because I’m not too into the Microsoft ecosystem in the first place.


As with Google Cloud, Azure certifications are a living moving thing: they evolve over time and are less like snapshots of an era. In addition to this, they (rather painfully) retire courses and arrange their course palette pretty often. I did all my certs in Jan-Feb 2018 by doing 70-535, 70-533 and 70-473, acquiring MCSE, MCSA and MSP certificates. Writing this blog post I noticed that a) MCSE, MCSA and MSP are no longer a thing, but the certifications are now role based (like with AWS and GCP) and, b) all my exams (except for 70-473) have been retired.
All the new certifications can be found here You might find some resemblance with AWS certificates, as the naming convention is conveniently pretty much the same. One thing still differentiates Azure from AWS and GCP; you don’t always do a single exam to earn a certificate, sometimes you have to do more.  Also, the certs have prerequisites, which is something that AWS gave up in 2018. You can find all the exams here:
Here is a chart of certs and correlating exams:

Azure Fundamentals AZ-900
Azure Administrator Associate AZ-100
AZ-102 (transition exam for people who passed Exam 70-533)
Azure Developer Associate AZ-202 (transition exam for people who passed Exam 70-532)
Azure DevOps Engineer Expert AZ-400 (in beta) Azure Administrator Associate or Azure Developer Associate
Azure Solutions Architect Expert AZ-300
AZ-302 (transition exam for people who passed Exam 70-535)
Azure Administrator Associate or Azure Developer Associate

The transition exams will retire in June 2019 so if you want to upgrade your certs, do so fast. I thought I would be done with certs for a while, but it’s possible that I’ll spend a day this spring studying the AZ-302 and trying the transition exam. I’m not especially thrilled by this change of plans, but I’d hate to waste all the time I spent doing Azure exams either.

Exam preparation

Even if the exams have changed, I think the training methods for Azure still stay the same. When I searched for viable online courses the pretty much only good source was Scott Duffy at Udemy and I know a few other people who have passed the Azure certs by following his advice. I’m quite confident that I saw Scott’s courses also on at some point, but can’t seem to find them there anymore.
You should also use Microsoft’s special offers when they are applicable. Usually, you get an exam, an exam retake and a practice exam with the price of only a single exam. As the exams are new though, first check for the availability of the practice exam; sometimes it takes time before the practice exams can be bought. The practice exams give you a good insight into the exam area and instead of just ”right” and ”wrong”, also guidance on where you can learn more about the subject. Model of the exam and a free retry also give some room for experimenting (or brute force) also taking off some pressure from the exams.

Taking the exam

Where Azure shines is that you can take the exam at your workplace or at home, given that you have a webcam and a mic on your machine. The exam situation is rather silly as they inspect a lot of stuff in the room and on your body, but you can schedule an exam for the same day and get done with it. The system failed me only once, so to learn from my mistake: if you do the system check early on (which I suggest if you have never done Azure exams this way before) then do the system check the same day as the exam. For me the exam software failed somewhat miserably as there was a new update that wouldn’t start, robbing me of a single exam try. As it was a software failure, I managed to get a new try for free, but I had to wait a week for the issue to be diagnosed, during which I couldn’t try the exam again.
Phew. This concludes the blog series on cloud certifications. The rather anti-climactic ending was not of my design, as my exam specific knowledge became obsolete in one giant whoop. If you are interested in cloud and already have some experience with it, check if some of our open positions would suit you at

Other posts in this series:

Part 1: Introduction to cloud certifications
Part 2: Amazon Web Services (AWS)
Part 3: Google Cloud Platform (GCP)

Tero Vepsäläinen

Tero is an ops-guy, coach and a service manager. He is responsible for the operative side of Gofore Cloud. He also likes to keep his hands dirty by planning and implementing cloud native systems.

Piditkö lukemastasi? Jaa se myös muille.

(How to) combine work and holiday

working holiday
Well, that’s a slightly misleading title, as I don’t know how it happened, it just did. At the moment I have the privilege to work as a Senior UX Developer for one of our clients, working across multiple teams in different locations (the client identity is subject to an NDA). I always wanted to work across borders, combining my two passions, design and travel. So recently I spent 20 days on holiday and 7 days working in the clients Manila office.
Those who know me will know that perhaps the only way I recharge and re-energise my self is by freediving and travelling as far as possible. So for the Christmas holidays, I chose the Philippines as I did last year. Naturally, I discussed my travel plans with my awesome team and the client. When I had a friendly chat with the client regarding the destination etc., we figured that there might be an opportunity to give some UX and DT training and workshops for the rest of the team in Manila to align the UX processes with the team in Espoo Finland. I found this super exciting since I have travelled all over Asia but never for work.

The holiday

This is my second time in the Philippines and definitely not the last. For anyone that likes friendly people and unspoiled nature, the Philippines is near perfect. My itinerary for 4 weeks was Helsinki > Manila > El Nido > Linapacan > Coron > Rock Island > Manila > Helsinki. Linapacan is special, in every way. First, it has 15 000 inhabitants and tens of uninhabited islands. Moreover, Daily News Dig claims that it has the clearest water in the world and based on my experience this is definitely true.
beach scene
I spent 6 days on a boat, swimming, freediving, spearfishing, watching the sunset and occasionally camping on a virgin white beach. I won’t go into more details, but feel free to ask me anything in the comments below 
free divingcockerel on a boat

The People

“It’s more fun in the Philippines” is the slogan of the country and it’s surely due to the people. I had the pleasure of meeting Filipinos in the rural provinces as well as in the city. Generally speaking, they are extremely friendly, happy and looking to help in any way. Also, I did not encounter any scams like in many other places in the world, however, it doesn’t mean that there aren’t any but it’s definitely uncommon. Professionally, I found that the work environment was less formal than I have found elsewhere. Employees and managers were very relaxed and had constant gags and laughs with each other and had created a great working environment despite long hours and modest salaries.
beach scene

The City

Metro Manila is the world’s most densely populated city with 43,079 people per square kilometre. This 21.3 million inhabitant metropolis is like many others; It is super fast-paced, notoriously congested, filled with skyscrapers and has more than a 100 gigantic malls. Yet, there was a different vibe, it looked drastically different in the dark as it comes to life when countless food-stalls rollout, some sing karaoke on the pavements and there are many other details that are only understood when experienced.
Here are some images from around the area of Cubao in Quezon City near my accommodation.
city life  city life  street food
This is also Manila from the top, as you can see, it’s super modern and up to par with any other metropolis hosting the 2nd largest mall in the world, Mall of Asia.
Manila Skyline . Mall of Asia Manila
I’m not exactly a city boy, but I had to stay for a week in Metro Manila to coach my Manila team on design thinking and UX practices and had to make the best of it! In the process, I have made some friends and met many interesting people. As for the public transport, mostly I used Grab, a popular taxi app in South East Asia. I must say, I found out that it was about 50x more expensive than public transport such as Jeeps, vans and busses. However, I have tried the alternate solutions, not just to save money but also to mingle with the locals and it was highly confusing. Although I was lost all the time, I recommend it. As you can see the UX of these transportation means could be improved.
Can you see the bright green sign that says Cubao? Yeah, you have to spot that from a far distance.
Jeepney   Jeepney
There is a movie playing during the bus ride which made me miss my stop, for the third time. As for those signs on the bus windshield, they were all flipped the wrong way round  Nonetheless, it was a great experience. And the fare was about 10php (€0.17) for an hour ride.

Is it safe?

Yes! As long as you practice basic safety logic as you would anywhere else. I did not encounter any safety issues, nor did the expats that I have met.
However, the Philippines lies within the ring of fire, in other words, it is prone to many natural disasters. For example, there were 21 typhoons in 2018. In fact, a typhoon (Usman) hit whilst I was on ”Rock Island”, a tiny islet where we had to cross with a small boat to the other side to get to the airport. Without dramatising it even further, let’s just say that our boat flipped, which took us 2 hours to rescue everyone and I ended up with a minor injury, but luckily no one else got hurt and it has made the adventure, a real one. Do your research and monitor the typhoons before going, but do not let it stop you from going to the Philippines.

The Work Culture

I can not speak on behalf of the whole tech industry nor the team in Manila, rather I will tell you about my brief experience. I was suspecting a more uptight, corporate environment like it is in many European corporations. However, I was pleasantly surprised to find out that they had a very similar culture to us at Gofore! It was fun, there was a strong communality feel and many employees spent time after work and even weekends together. They had subcultures of gamers, cyclists, artists and they were all foodies! The most pleasant surprise was to see about 35-40% female presence in an engineering and SW development environment. Many also mentioned that this is on the rapid increase and could soon change to be at least even. Something for the rest of the western world to learn from as currently only 20% of jobs in tech are held by women.
What was less great, however, was the working hours that were from 10:00-19:00 or 11:00-20:00 to compensate for the time difference with Europe. In fact, I met someone on the bus, who was an accountant at one of the largest firms that basically works night shifts to compensate for the time difference to the US.

So, what did you do there?

What I did was to facilitate workshops and training for designers and non-designers. The aim was to show them alternative ways of thinking about the users, regardless of their role. Many have not heard of UX and others have worked with UX designers, so I had to figure out a way of engaging participants from all levels. So over the course of 3 days, I started by giving a gentle introduction to design thinking, followed by an interactive crash course in DT and ending with a more specialised and focused approach to lean UX. The feedback was very positive, with many questions about our way of working in Finland creation and UI design. Also many requests for more training into user research, persona creation and UI design.

Gofore ❤ (heart) The World

I always find it both a valuable and an unforgettable experience to work far from home with a different culture and climate compared to Finland. After such a trip I feel highly energised and inspired to come back and innovate. This trip was also a great reminder, that no matter what the country, language, nationality, gender, climate and culture is there is always a match for Gofore. Yet there is no substitute for working and living in a different country and experiencing life as a local which gives me a great feeling regarding Gofore’s future and internationalisation plans.

Anmar Matrood

Anmar is a designer with a strong background in UX and visual design. His passion is to simplify complex UX problems and his goal is to make intricate information accessible to the masses. Anmar is also an avid freediver, photographer, traveller and researcher.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

Scrum pähkinänkuoressa

Scrum on vain työkalu. Tässä esiteltävä vakiomuotoinen Scrum on lähtökohta, josta on hyvä lähteä liikkeelle, kun aloitetaan ihan alusta. Pidempään yhdessä toiminut ketterä tiimi voi muokata Scrumia loputtomiin, tai vaihtaa toiseen työkaluun kuten Kanbaniin, tai Scrumbaniin. Prosessisuunnittelussa kannattaa ajatella ”Love the problem, not the solution” – rakasta ongelmaa, älä ratkaisua. Tällöin asiakkaan tarpeet pysyvät päällimmäisenä – eivät omat hienot ideat tai idealismit, joihin on aina niin helppo rakastua. Samaa tarkoituksenmukaisuutta ja jatkuvaa kehittämistä peräänkuulutettiin aiemmassa blogissani.
Määrämuotoinen Scrum prosessi on turvallinen ensimmäinen askel ketterään kehitystyöhön, missä isomman tiimin kesken rakennetaan pidemmän aikaa jotain uutta. Scrum ohjaa lyhyen ja keskipitkän aikavälin suunnitteluun, sekä säännölliseen palauteluuppiin niin sisällön, kuin työtapojen suhteen. Jos tehdään nopeampirytmistä ja reaktiivisempaa työtä, niin virtaustehokkuuteen ohjaava Kanban on parempi organisoitumismalli. Jos taas tehdään jotain pitkälle etukäteen määriteltyä, niin voidaan palautesykliä harventaa ja edetä enemmän vesiputousmallin kaltaisella prosessilla.
Scrum itsessään on paradoksi; samalla kun ketterät periaatteet vaativat yksinkertaisuutta, Scrum määrittelee melko mutkikkaan prosessin, jonka käytöstä, hienosäädöstä ja kehittämisestä on kirjoitettu lukemattomia kirjoja. Schwaberin prujussa vuodelta 1997 Scrum kuvattiin alkujaan ytimekkäästi:

  1. Ennen peliä analysoidaan tilanne ja tehdään projektisuunnitelma; mitä, kuka, milloin, mitä maksaa
  2. Pelin aikana pyöritetään Scrum sykliä
  3. Pelin lopuksi julkaistaan, dokumentoidaan ja vedetään yhteen miten projekti meni.

Ja nyt kaksikymmentä vuotta myöhemmin Cockburn taas pyrkii omalla The Heart of Agile kampanjallaan palauttamaan mieliin, että Scrumin ketterät periaatteet ovat yksinkertaisia:

  1. Kunhan tiimi tuottaa jatkuvasti lisäarvoa, niin prosessilla ei ole niin väliä
  2. Tiimi päättää miten toimitaan
  3. Arvioidaan aktiivisesti mitä ja miten toimitaan, sekä pyritään parantamaan
  4. On olemassa vastuuhenkilö, jonka vastulla on reagoida ilmeneviin esteisiin (Scrum Master)
  5. On olemassa vastuuhenkilö, joka päättää liiketoimintatavoitteet (Tuoteomistaja).

Ketterät periaatteet

Scrum perustuu ketteriin periaatteisiin, jotka ovat tiivistettynä:

  • Tiimin tuottama lisäarvo muodostuu usein ja säännöllisesti asiakkaalle toimitettavasta, toimivasta ohjelmistosta.
  • Asiakkaan prioriteetit saavat muuttua. Projektin edetessä opitaan lisää ohjelmistosta, käyttäjistä, sidosryhmistä ja toimintaympäristöstä. Tämän myötä on täysin ymmärrettävää, että lyhyen aikavälin tavoitteet muuttuvat. Toisinaan myös pitkän aikavälin tuotevisio muuttuu.
  • Kaikki projektiin osallistuvat ovat motivoituneita, innostuneita ja tasa-arvoisia. Vaikka projektissa seurataan tiettyä prosessia ja rooleja, niin aktiivinen kommunikaatio on tärkeämpää, kuin itse prosessit.
  • Ihminen on sosiaalinen eläin, joka kommunikoi tehokkaimmin kasvotusten. Tämän vuoksi olisi hyvä ajoittain tavata kasvotusten.
  • Työssä seurataan jatkuvan parantamisen sykliä, jolla pyritään parantamaan toimintaa, niin ohjelmiston, arkkitehtuurin, prosessien, yhteistyön, kuin motivaation ja innostuksenkin kannalta.
  • Pyri kaikissa edellä mainituissa yksinkertaisiin ratkaisuihin.

Suuresta pieneen

Sen sijaan, että iso joukko ihmisiä toteuttaa isoa asiaa pitkän aikaa, Scrumissa pieni joukko ihmisiä toteuttaa pientä asiaa lyhyen aikaa, mutta säännöllisesti integroiden kokonaiskuvan kirkastamiseksi.

KUVA: Pilko ihmiset 7 +/-2 hengen tiimeiksi

KUVA: Pilko asia niin pieniin osiin, että ne on mahdollista toteuttaa yhden iteraation aikana, yhden tiimin toimesta. Järjestä osat tärkeysjärjestykseen siten, että eniten lisäarvoa tuottavat ja vähiten työtä vaativat asiat tehdään ensin (weighted shortest job first)

KUVA: Pilko aika lyhyisiin 1-4 viikon iteraatioihin, joista jokaisen päättyessä demonstroit sidosryhmille koodin toiminnallisuutta aidossa ympäristössä

Scrum roolit

Scrum tunnistaa 3+1 roolia

  1. Tuoteomistaja vastaa tuotteen työjonon hallinnasta. Tuoteomistajan vastuulla on huolehtia, että tiimi tuottaa mahdollisimman paljon lisäarvoa sidosryhmille.
  2. Scrum Master auttaa tuoteomistajaa ja kehitystiimiä Scrum prosessin optimoinnissa, sekä poistaa esteet.
  3. Kehitystiimi on joukko aktiivisia ja yhteistyökykyisiä kehittäjiä, jotka rakentavat toimivan ohjelmiston ja rakentamista tukevan kehitysympäristön.
  4. Sidosryhmät ovat ulkoisia toimijoita, kuten loppukäyttäjät, hankehallinto tai muut Scrum tiimit.

Scrum prosessi

Scrum prosessissa on 4+1 vaihetta. Vaiheet ovat aikarajattuja, eivätkä koskaan mene yli ajan.

  1. Sprintin suunnittelu: Kehitystiimi valitsee tuotteen työjonon yläpäästä sen verran käyttötapauksia, kuin uskovat sprintin aikana saavansa toteutettua. He asettavat yhdessä sprintille sanallisen yhden lauseen mittaisen vision. Tämä tavoitevisio yhdessä valittujen käyttötapausten kanssa muodostavat sprintin projektisuunnitelman. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h suunnittelupalaveri.
  2. Daily Scrum: Tiimiläiset kertovat vuorollaan
    1) mitä saavuttanut edellisen dailyn jälkeen,
    2) mitä aikoo saavuttaa ennen seuraavaa dailya,
    3) mitä esteitä tavoitteelle on.
    max 15 minuuttia, teknisiä keskusteluita voi jatkaa dailyn jälkeen, mutta dailya ei venytetä.
  3. Tuotteen työjonon kirkastaminen: Tuoteomistaja, tiimi ja tarvittaessa paikalle kutsuttavat sidosryhmät pilkkovat ja tarkentavat tuotteen työjonolla seuraaville sprinteille priorisoituja käyttötapauksia. Tuoteomistajan tavoitteena on kirkastaa seuraavien 2-3 sprintin suunta. Tiimin tavoitteena on auttaa tuoteomistajaa tässä ja ymmärtää tuoteomistajan seuraavien sprinttien visiota. Tämä on luonnollista aikatauluttaa puoliväliin sprinttiä, eli 2 viikon sprintissä joka toinen viikko on sprintin suunnittelu ja joka toinen viikko työjonon kirkastaminen. Kesto 1h per viikko, eli jos 2vk sprintit, niin 2h kirkastuspalaveri.
  4. Sprinttikatselmointi: Demotaan ylätasolla projektin ulkopuolisille sidosryhmille, kuten loppukäyttäjille ja bisnesihmisille, mitä on saatu valmistuvassa sprintissä aikaan.
  5. Retrospektiivi: Scrum Master vetää tiimin avustuksella yhteen miten edellinen sprintti sujui. Saavutettiinko sprintin visio, valmistuivatko valitut käyttötapaukset, onnistuiko demo, mikä meni hyvin, missä on parannettavaa. Näistä valitaan muutama parannusehdotus seuraavaan sprinttiin kokeiltavaksi. Kesto 45min per viikko, eli jos 2vk sprintit, niin 1:30h retro.

Jari Hietaniemi

Jari Hietaniemi is an enthusiastic digitalization consultant. He specialises in complex and vast software projects. His philosophy is based on thinking that a consultant must know technology, architecture, project management, quality assurance, human resources, coaching and sales. His versatile experience and constant quest for improvement help to finish projects successfully and to bring new drive into client organizations.

Linkedin profile

Piditkö lukemastasi? Jaa se myös muille.

In this blog post, it becomes obvious that out of all the certification paths available I’ve chosen the one more related to the Ops-side of the DevOps-spectrum. I’ve been there when infrastructure couldn’t be considered a code when a server needed fitting into a rack*, and never written ”real code” in my life apart from simple Perl/Python scripting. With cloud, I’ve continued to build upon that foundation. This reflects my certifications: I’ve done the Ops-path, but left the Dev-side totally untapped (this trend continues on the next [Azure] blog post). After doing my share of cloud certifications, I’ve dipped my toes into the realm of modern web programming. Does this mean that I should do the Dev certs next? Nope. The Pro level certs take a lot of time and I don’t see the investment of my free time paying back any time soon.
* Yes, cloud computing is just a cluster of computers that also needs fitting into a rack and petting, but it’s not really a mainstream job for a system administrator anymore, is it?
Ok, enough of my motivational circumstances. What about GCP then? I think out of all the clouds it’s the most user-friendly: the web console is just way better than AWS’s, the shell you get on the web console is nice and I would totally like to use App Engine on a project (with live debugging and other shiny thingies). Stackdriver as a whole still feels a little weird to me, but it has tons of functionality. And with the Google Kubernetes Engine being somewhat the best in the business, I would choose GCP whenever I’d have to run a container production load.


I’ve done the Associate Cloud Engineer and Professional Cloud Architect certs. There are also Professional Data Engineer and Professional Cloud Developer certifications and even one on G-Suite, but I’ve got no experience in those. Unlike AWS and Azure, Google actually does it’s own web training.. and they are far better than any of the 3rd party ones. How great is that! They also send you some (mostly useless) swag when you complete any certificate, which is a nice gesture.
You can find all the exams here
some Google SWAG
Picture1: The least worst swag I got from Google

Associate exam

I did the Associate Cloud Engineer beta exam as a sort of practice exam for the professional one (because why not?). It took a few months for the exam results to arrive (for beta exams it tends to be that way). I’d actually totally forgotten about the whole exam by then, and it turned out that that I was one of the first one hundred to get the certificate. The exam was the least theoretical cert exam I’ve ever completed. If I’d have to give any hints, it would be to get familiar with the web console and SDK Tools. Use them, preferably in a practice project. Yes, you have to know some commands. Yes, you have to know where stuff is in the web console. This is an exam for a Cloud Engineer, it measures how well you can do stuff.

Pro exam

Out of all the cert exams I’ve done, the Professional Cloud Architect was my favourite; hard, but interesting. It threw really-really-really odd curveballs at me that couldn’t be prepared for and learning trivia by heart had no value in this one. It measured if you knew your cloud and it means everything that comes with it. It was also the exam I spent the most time studying for. I think it took some three months at one to two hours/day for me to get comfortable with the whole exam area.

Study materials

For both the associate and pro I suggest the Google made Architecting with Google Cloud Platform Specialization. It might be a little too deep for the associate, but better too deep than too shallow.
Also for the pro, I would supplement the studying with the following:

Also as Google’s certs are a moving target (they get updated constantly) keep up with the news on their blog and I strongly suggest that you watch the Google Next speeches on relevant services from ’18

Doing the exam

At least in Finland, you can only do the exam as a proctored exam, where someone observes you doing the exam, and is only available in either Espoo or Helsinki. You can reserve your exam time in
Unlike AWS and Azure at the end of the exam you get information whether you passed or not, but no indication on how well you fared. No points, no percentages, nothing. I think this can be extremely frustrating for people who do not pass the exam, as they have no idea of whether they were even close. Just hope you’ll see the ”you passed”-message and to get to order some swag for yourself.

Shameless marketing

I’m also head of GDG Cloud Tampere and we’ll be hosting many nice events this year. Join the fun at

Other posts in this series:

Part 1: Introduction to cloud certifications
Part 2: Amazon Web Services (AWS)
Part 4: Microsoft Azure

Tero Vepsäläinen

Tero is an ops-guy, coach and a service manager. He is responsible for the operative side of Gofore Cloud. He also likes to keep his hands dirty by planning and implementing cloud native systems.

Piditkö lukemastasi? Jaa se myös muille.

My journey to cloud environments started with AWS. First I staggered through the internet trying to find a good guide for understanding cloud computing, different platforms and terms used. I spent considerable time on this (retrospectively) useless wandering until I started studying for the Solutions Architect Associate certification and got my first bite of well-structured course material on my first ever cloud: AWS. Even if some people consider certifications silly and a waste of time, the certification courses themselves are a brilliant way of grasping how a cloud platform works.
My personal opinion on AWS is that it may not be the most user-friendly platform, but it’s still the most versatile one out there. If there is something that you can do in cloud, you can probably do it in AWS. This being the case, I would choose AWS as a running platform unless there is some reason not to.
AWS's chart of all the certificates
Picture1: AWS’s chart of all the certificates


An up-to-date list of AWS’s certifications can be found here. No new associate or pro level certs have been added during the time I’ve been around the scene, but the existing exams have been slowly updated to match the AWS of 2019. The names of the certifications have stayed the same though. Unlike Azure and GCP where exams are kept up to date, AWS’s exams represent a snapshot of a given time. From the exam taker’s perspective this is a good thing, but from a practical implementation perspective, it’s a bad one. The exam-taker expects the study material to stay constant for years, and as such there are lots of exam material online to aid you. In practice, you end up studying old material and usually the newest Re:Invent stuff is not in the exams. The worst (or best?) example of this is the reserved instance classes (heavy/light utilization) that are obsolete and any official documentation can’t be found about them, but still, I’ve found questions on them on both Solutions Architect Associate & Professional exams. Both of these exams have now been updated, and I doubt there are any reserved instance class related questions, but in a few years, there will be something similar.
Certifications used to be valid for two years, with one year grace period with the option of doing a simple re-certification, even though your cert has expired. Because that system was rather confusing the new exams are now just valid for three years during which they can be extended by doing the re-certification exam. There used to be a requirement on passing a specific associate exam to even have the possibility to try a Pro cert exam, but this restriction was removed late 2018. This doesn’t mean that you should go straight for Pro certifications unless you have worked with the platform for years using a plethora of services.

Associate certifications

Picture2: Associate exams and shared material
Associate certs share around 70% of the same base of ”this is AWS”-material with each other concerning networking, IAM, storage etc. If you do the Solutions Architect Associate certification first (which I recommend) you can do the Developer and SysOps courses with few days of prepping. Should you choose this method? Well, it looks better on your CV but really it brings little extra to the table. The Developer certification material more thoroughly covers parts of the developer centred material such as DynamoDB and SysOps and has some more details on OpsWorks and Elastic Beanstalk. You really only have to study the difference between your first associate exam and the new one you’ll be doing. If you got a sponsor for your exam fees and you want to boost your CV, go for it.

Professional certifications

The pro level exams cover some common ground with each other, both being AWS exams, but they share fewer details when compared to the Associate exams. For me, It took a few months to study for both exams individually. I initially started reading for the DevOps Pro right after I got my associates done, but it was too steep a hill for me to climb, and I ran out of motivation around halfway through the course materials. One year later with actual AWS projects under my belt, I read through the materials which now felt easy and passed the exam quite easily. I tried studying for the Architect Pro after that, but hit that familiar wall once again, fast forwarding to 1 year of AWS projects and told my colleague how ”this course material brings very little new to me” and passed the exam.
For professional certifications I have only one piece of advice:
Do. Actual. Projects. On. Cloud.
After that they are easy.
I think that owners of Pro level certifications are somewhat respected if such a term should appear in your CV but once again I don’t really think there is much difference if you have one or two.

Speciality certifications

Unlike general ones, the specialities share very little with each other, only concentrating on one thing and going deep into it. I have to admit that I haven’t done any of the special certs, only skimmed through their content. I intended to do the Advanced Networking certification, but gave up around half-way through the course material when it was going through BGP’s finest details. As AWS certificates go, they are quite new with new ones coming every now and then, so I don’t know how much reputation you get by passing them.

Study Materials

I totally and wholeheartedly suggest that you use for studying. The guys and gals there are doing a fabulous job on online courses. has a practice exam (usually) at the end of their course, which is quite sufficient. You can also buy a practice exam from AWS with some 20 questions, but it’s usually badly written and even if you know your stuff (and pass the actual exam) you might end up with just 60% of the questions correct. If you are feeling cheap and you are gonna do only one certificate, you can grab a course dirt cheap from; they have a sale going on every day.
In addition to I complimented the materials with those on on Pro Solutions Architect course, as at that time there were no practice end exam options on and I felt that some of the services were not explained in enough detail.
I read every whitepaper that is suggested in the courses, and I also read FAQs and documentation on the most important services. As noted on the first blog post on this series do the following:

  1. Read the certification requirements
  2. Take part in a web course that goes through the relevant material
  3. Read the documentation for the most important services
  4. Do some practice exams
  5. Ace the exam

What I did forget to mention though, is using the service. For every service on the exam, you should use the actual service. If you got a pet project to use them on, great. If you don’t, just click through the dialogues so that you understand every option and how it influences the end result. For Pro certs you also have to do some work with cloud computing, otherwise, the wall is too high for you to climb, sorry.

Doing the exam

You can reserve your exam time on If English is not your first language, remember to mark so on the portal BEFORE reserving the exam; this gives you some extra time. You can do this on the AWS Training and Certification portal by clicking ”Upcoming events”→”Request Exam Accommodations”→ ”Request Accommodation” → ”ESL +30 MINUTES”.
The options are basically to do a monitored exam where a person watches how you are faring, or use a kiosk. In Finland, the observed options are located in Helsinki and kiosks can be found in Helsinki and Tampere. There has been a lot of conversation about the kiosk PCs booting in the middle of the exams, possibly multiple times, and how they are monitoring if you cover your mouth, thus creating more stress. Personally, I liked the kiosk experience, as I could do the exam on the other side of the road from our office in Tampere. Yes, the passport recognition mechanism was broken, as told by the receptionist, and the person on the other end of the line wouldn’t or couldn’t understand that, requiring me to start exam registration a few times over, but the exam itself went quite smoothly.
Right after the exam, it tells you how did you fare and in a few minutes you get the results also to your email, with percentage grading on different areas of the exam.

Other posts in this series:

Part 1: Introduction to cloud certifications
Part 3: Google Cloud Platform (GCP)
Part 4: Microsoft Azure

Tero Vepsäläinen

Tero is an ops-guy, coach and a service manager. He is responsible for the operative side of Gofore Cloud. He also likes to keep his hands dirty by planning and implementing cloud native systems.

Piditkö lukemastasi? Jaa se myös muille.

This blog post is the first of my new blog post series that will be published in the following weeks. The aim is to cover getting certificated on all the major cloud platforms currently (1/2019) in Europe: Amazon Webservices (AWS), Google Cloud Platform (GCP) and Microsoft Azure. I’ve done my Pro level certs on all these platforms quite recently (within a year), so I’ve some knowledge on the issue. I’ve written texts similar to this on our internal wiki, but as there are no secrets in there, I decided to re-write the material in a more reader friendly format (and less like a stream of consciousness).
Like the good authors of certification guides I’m not claiming that you will get certified by doing what I advice you to, but I can safely say that following my advice raises your probability of success.
This first blog post is labelled ’introduction’. I’ll cover general stuff about certifications, suggested path for going through the clouds (for the hardcore ”gotta get ’em all”-cloud people out there) and also some general notes on preparing for the certifications. The later posts will each focus on one of the cloud platforms.
The three musketeers

Correlation between getting a certification and knowing your stuff

Before going to the actual how-to part, let’s think for a while what a certificate actually is and does getting one hold any significance. Being a holder of a certificate means that you have passed an exam where your general knowledge on the platform has been tested. Depending on your path (development, architecture etc.) your knowledge goes a little bit deeper on certain areas, but you most likely need to know the same basic stuff on all associate-level certs for a single platform. For pro level exams, it means that you also possess some deeper level of knowledge on the subject and also possess problem-solving skills giving you the title Pro; a professional proficiency on the subject. This is not to be mistaken with a guru. Does a certificate make you a cloud engineer, to be quickly hired and put to a challenging customer project? Pro level cert certainly would imply that, but associate? No. An associate cert is a first stepping stone, meaning that you know some rules and best practices on the subject, but without any elbow grease on the platform, it amounts only to a good start. Of course, you can just put your study-cap on and study like possessed and pass a pro exam without never even launching a single instance, but I dare to say that it’s quite an uncommon scenario.
Why bother with associate certifications then? Well, as said previously, it indicates that you know the best practices of the platform, and while that might not land you your dream job, it’s still a quite big deal. When working in a cloud environment it’s very easy to deploy applications and create virtual machines, but it’s also really easy to do them wrong, using architecture not fit for cloud-age or in a worst case compromising security. Yes, you could just watch the videos and read the documents and be equally knowledgeable on the subject as someone with a certificate, but if you took all that time to study, why not do the certification when you are on it.

Clouds and order of conquest

If your work or side projects do not involve using any of the platforms and you are totally free to choose where to begin, I would (once again) pick AWS. AWS is by far the market leader and mastering it still opens more doors than GCP and Azure combined. If you are more curious for example about GCP, pick that. In studying practicality falls second to motivation.
If you really have a lot of free time on your hands and want to get certified on all the cloud platforms you can start wherever you want… but if you start with either AWS or GCP, do the remaining one before going for Azure. Terminology- and function-wise AWS and GCP are quite similar to the extent that Google has published even a quite handy cross-reference document from AWS experts to grasp their platform. Where terms for higher levels of abstraction are also similar for Azure, such as block storage and object storage the Microsoft way of doing cloud is still quite different. Understanding Azure requires you to forget how stuff is done in other cloud platforms and learn the Azure way. I did the AWS →  Azure → GCP trip and cannot recommend it to anyone.
Why use one sentence to describe the cloud platform study order, when you can confuse the ***t out of people with a diagram

Actual studying

An easyish path for studying for a certification goes like this

  1. Read the certification requirements
  2. Do some web course that goes through the relevant material
  3. Read the documentation for most important services
  4. Do some practice exams
  5. Ace the exam

Certification requirements and service documentation will be produced by the cloud platform organization and readable on their websites. Web courses and practice exams are usually provided by some third party, I will give hints on good places for platform-specific blogs of this series.
If you spend one hour daily, you should be able to do your first cloud certification in two months, even without previous experience. I suggest that before trying any of the Pro level certifications you get hands-on experience with some cloud platform for at least one year. It does not have to be that specific platform, as usually on those exams emphasis is more on ”cloud thinking” and less on trivia.

Exam tactics

Even if there are differences in how the exams are done on different platforms, there are some universal strategies:

  1. Book your exam when you start studying
    • It works as a goal for your studies, giving that small ’oomph’ to your motivation
  2. In the exam, don’t get stuck, time is of the essence
    • Mark the hard ones and come back later
  3. Don’t overstress
    • Even if you fail, you can always try again. You’ll also benefit from failure: now you know your weak points and can improve on that

Follow-up posts in this series

Part 2: Amazon Web Services (AWS)
Part 3: Google Cloud Platform (GCP)
Part 4: Microsoft Azure

Tero Vepsäläinen

Tero is an ops-guy, coach and a service manager. He is responsible for the operative side of Gofore Cloud. He also likes to keep his hands dirty by planning and implementing cloud native systems.

Piditkö lukemastasi? Jaa se myös muille.