Ivan Čuljak

Ivan Čuljak

Cloud Solution Architect @ Celeste Maze

Ivan is a .NET freelance developer in love with Azure, Xamarin, and the idea of automating whatever. He's also an Microsoft MVP for Azure <3. When he’s not developing something new, he’s salvaging something inherited, consulting with enthusiasm, and testing and breaking new technologies in a quest for something useful.

Ivan Čuljak

Cloud Solution Architect @ Celeste Maze

Ivan je .NET freelance developer koji voli Xamarin i Azure, a obožava automatizirati što god je moguće. Također je i Microsoft MVP za Azure <3. Kada ne razvija nešto novo, spašava nešto naslijeđeno ili savjetuje (još uvijek) s entuzijazmom, testira i ruši nove tehnologije u potrazi za nečim iskoristivim.

Current sessions

Are you scared of your DevOps process?

We all "know" that we should automate whatever possible to reduce the risk and time to market, but how confident are you about your process?
Sure, your CI/CD might work properly 100x a day for the DEV environment, but are you using the same tested pipeline for PROD as well? Can you easily rollback? Are you completely sure?
Let's dive deeper into getting you a bit more relaxed 😉


Congrats... you're all alone on a project... now what???

This talk is based on a true story :)
A lot of developers eventually end up all alone on a project. This usually happens when they start freelancing or building a project all by themselves.
Reasons for being all alone on a project when freelancing can be limited budget, maintenance mode, developers wanting to over-deliver, and a whole array of others.
The problem with those projects is that if that single developer sticks to "team workflows" he/she will waste a thrid to half of a day every day. On the other hand, going in without any workflows leads to total chaos.
So.. where's the middle ground, not only in workflows, but also in tasks/stacks which you should handle? When should you pull a brake and sort things out, and when is the "right" time to close your eyes, cross your fingers and hope for the best?
Well, this talk is an attempt to bring clarity into your mind about those things, and to tell you that you're not alone ;)


Multi-cloud multi-tenant serverless crawlers

Crawlers are always a cool topic, but they take a second role in this talk.

One day we've decided that running and taking care of a bunch of VMs in various regions, only to crawl the web from them, is tedious, not so scalable, and honestly we needed a new hobby project.

The idea was to build a system which can spin up some computing resources across the globe with a wide range of IP addresses without having to use proxies. The system also had to be scalable, require as little maintenance as possible, hopefully cost less than the current one to run, and since we were getting requests from some potential clients - it had to be multi tenant.

During this talk you'll be able to learn why did we go with serverless containers instead of serverless functions, how are we automatically provisioning infrastructure on a need basis on three clouds, how are the requests and responses flowing through the system, etc, etc.

Basically, at the end of the talk you should have a general idea on how to build your own system which spins up and down various tasks on multiple clouds.


Developing Azure solutions while dreaming of multi-cloud [WORKSHOP]

Let's face it... developing a proper solution for a single cloud is hard enough, so building a proper multi-cloud solution is something you can only dream of... or is it?

Each cloud is a bit different, and each cloud allows you to lock yourself into their solutions, making it difficult/expensive to even think about another cloud. But that's something you've done to yourself... the cloud only allowed you to do it, the cloud isn't the "bad guy" in this story.
To avoid these situations, you should understand what are you getting into, hopefully before you start developing.
That's why we're gonna start with some common, and some less common cloud patterns.

Once you get a general understanding of those, we'll start building a cloud solution on Azure. We're doing that because the usual path is to go with a single cloud first, but this time you're gonna learn how to properly structure the whole thing to avoid shooting yourself in the foot.

After we build something more complicated than a hello world, we'll make it yet more complicated by introducing additional regions to your solution, and all the problems which come with replicating data and thinking about consistency.
Mind you... we're still only on Azure at this point.

Once we wrap all those problems, we're gonna start introducing AWS and Google Cloud to make the whole system more resilient.
Since this will introduce a whole lot of possible problems, brace yourself, but be calm since you've built your initial system with some cloud patterns in mind 😉

As the day will come to an end, we'll have a multi-cloud system, but we won't be sure whether there's any use of it, so... what better way to end the day than doing some chaos engineering.


Developing Azure solutions while dreaming of multi-cloud

Let's face it... developing a proper solution for a single cloud is hard enough, so building a proper multi-cloud solution is something you can only dream of... or is it?

Each cloud is a bit different, and each cloud allows you to lock yourself into their solutions, making it difficult/expensive to even think about another cloud. But that's something you've done to yourself... the cloud only allowed you to do it, the cloud isn't the "bad guy" in this story.
To avoid these situations, you should understand what are you getting into, hopefully before you start developing.
That's why we're gonna start with some common, and some less common cloud patterns.

Once you get a general understanding of those, we'll start building a cloud solution on Azure. We're doing that because the usual path is to go with a single cloud first, but this time you're gonna learn how to properly structure the whole thing to avoid shooting yourself in the foot.

After we build something more complicated than a hello world, we'll make it yet more complicated by introducing additional regions to your solution, and all the problems which come with replicating data and thinking about consistency.
Mind you... we're still only on Azure at this point.

Once we wrap all those problems, we're gonna start introducing AWS and Google Cloud to make the whole system more resilient.
Since this will introduce a whole lot of possible problems, brace yourself, but be calm since you've built your initial system with some cloud patterns in mind 😉

As the day will come to an end, we'll have a multi-cloud system, but we won't be sure whether there's any use of it, so... what better way to end the day than doing some chaos engineering.


Cloud architectural patterns 101

Cloud has been a buzzword for almost ten years now, but still, a considerable portion of systems isn't "up there". The reasons vary from being scared through not having enough time to investigate it properly, to valid legal and/or technical reasons.
It's easy to get started and not so easy to make it right. Cloud requires serious thought and serious investment into learning the new concepts before one can understand what the trade-offs are.
We all heard of the horror stories of raking incredible fees by simply not understanding that having the infinite scaling set up creates infinite cost scaling as well.
Through many demanding migration projects, I realized there is no way I can satisfy the demand. There is simply no way to teach many organizations to bootstrap their cloud efforts right. So, I built the solution for that demand - a concentrated solution based on the verified, battle-tested configurations I made for clients throughout the years. One with proper security in place and tailored for real-world scenarios I encountered in my work.
The goal was to ease the migration, cut down the migration cost and duration, and increase the reliability and stability of the new system. But to make something like it, you first have to figure out which "templates" fit most of the use cases, and are a good fit to start extending for those cases which require more specializations.
Don't get me wrong... this isn't a sales talk, this is a talk about that journey, full of recommendations how to move to the cloud... any cloud, since the patterns and services are almost the same.
So please join to see us taking off the "mystery veil" off of the cloud, and discussing how to build your cloud native and/or hybrid cloud system without much fuss.


Taming the big bad cloud

Ever thought that everyone else is doing cloud for years, while you're still just a {fill_the_void}?
Ever been afraid of the complexity that cloud brings on top of all the dev frameworks or IT tools you need to use?
Let me tell you a secret – you're not alone.
The purpose of this talk is bringing the power and confidence back to you.
We'll focus on provisioning the cloud infrastructure and deploying to it, but not in a way that you'd think is black magic. What you'll learn is to identify patterns, and once you're able to identify patterns, you'll be able to apply templates.
All of a sudden, you won't be referring to the cloud as a big bad cloud, but as a "same old system" which you've tamed.
We'll start with defining usage patterns to cover most of your need, then continue with writing Infrastructure as Code to provision it (NB we talking about real, dev like code, not some markup languages or DSLs), only to end the talk with setting up automatic builds and deployments as easy as 1-2-3 😉


Something old, something new, something borrowed, something blue

This is a tale about how we've designed, built, and continue expanding an exciting cloud system. Don't get me wrong, every cloud system is interesting to me, but this one was challenging.
It all started with a short requirement „here's a desktop app, make a SaaS around it“ 😊
On this journey, we've tried almost everything and hit virtually every wall, but in the end, we've made it work. So let's see what do we have... something blue is obviously Azure.
Something borrowed is a desktop app that we're using through COM interop, and it's a crucial part of the system.
Something new represents serverless, event-driven architecture, containers, automated everything, you name it.
Something old represents virtual machines because a desktop app has to run on Windows, and we've made it scaleable, reliable, and self-healing.
Come and see how you can build a system like this needing zero manual maintenance.


Going Serverless on Azure

Not so long ago serverless was a cool thing to have, but not really that useful. Sure, you were able to run small scripts/functions without getting a nice bill, or worrying about the underlying infrastructure.
Times have changed, and serverless is almost a first class citizen nowadays. You can use it for serious stuff like APIs, data processing, linked complex systems, but you can still use it as a "helper" tool for your current systems.
Come, and join us to learn what can, and what still can't be done with Azure Functions, how can you mock APIs with them, and then transform it to a full fledged API action by action, how to place a gateway in front on them, how to chain them, how much should you worry about security, is it possible to just move your existing code, etc. We'll also go through orchestration with Durable Functions, serverless containers, connecting everything with both messages, and events, etc.
I promise it will be fun and useful ;)


Making the cloud event-driven, and orchestrated

Years have passed since serverless started being a hype. Tensions are lowered now, we’ve learned a lot in the mid time, we’ve figured out what for is serverless useful, and how to use it, but we’ve also figured out what are we missing, at least out-of-the-box.

One of the things we are/were missing is the ability to react on a broad spectrum of events in the same way, whether we’re talking abut a click on a web page, a message between parts of our system, an information that a virtual machine has spun up, or even that our credit card has bounced…

The other major pain is/was chaining of serverless functions, keeping track what, and where failed, decently handle errors, basically… having the whole system make us proud, instead of looking like something that MacGyver patched up during a single episode to flee from some narco boss.

Azure gave us EventGrid to solve the first pain while allowing us to event react to inter-cloud events, and we’ve got Durable Functions to orchestrate whatever we feel like.

The goal of this talk is to give you an overview what can you expect when you start playing with serverless more seriously, as to give you some advices how to make your serverless architecture more serious, more stable, and less demanding to constantly watch over your e-mail to see if something has crashed, and degraded.
If you want to hear stories from 18 months of serverless “trenches”, please join.


Building mostly serverless distributed cloud systems step by step

Serverless is definitely here to stay, and there are also more and more frameworks meant to ease serverless containers and functions development (even across clouds) becoming stable every day.
Although the idea behind serverless is not to worry about the infrastructure, you still need to worry about how long will it take to scale, and that's where things like cold starts, preheating, multiple deployments, and hybrid environments come into play.
Basically, serverless is a great tool when used where needed, and that's the topic of this talk - learn how to build a serverless system, talk about some caveats, and discuss alternatives.

At the core of the system, we'll take a third-party system and pretend it's a legacy API, and then slowly build our distributed, scalable, geo-distributed and a tad cross-cloud system around it.

Containers will be used for tasks that take time, and some places where we need an immediate response. Durable Functions will be orchestrating the whole logic. We shouldn't forget about Service Bus Queues/Topics, but we'll also need Event Grid to connect various parts of the system. In the end, there's "nothing better" than API Management to be at the front.


Provisioning and deploying to serverless

Fear not... whatever you can do by using Infrastructure as Code can be done by hand through a GUI, given enough time... but there are probably better things to spend time on.
There is plenty Infrastructure as Code solutions out there, but there's a relatively „new kid on the block“ that plays extremely well with serverless and allows you to perform wonders in minutes/hours rather than days. Please welcome Pulumi.
Serverless stuff is charged per usage so there's no penalty if you've deployed five function apps instead of just one. The reason why we need five or fifty or five hundred of them are the limits on how fast, and how big can your function app scale.
Pulumi will take care of that, but we also need to deploy some software to those functions / containers / PaaS / etc. Not only that, but before deploying we need to fetch connection strings for DBs / storage / cache that we've just provisioned, and that's where the fun start. Trust me, you don't want to set up a release definition for five hundred function apps by hand, especially if they're scattered across multiple clouds.
That's where the fun starts and where you start connecting Pulumi with some scripts that handle you CI/CD. My tool of preference is Azure DevOps, and you're welcome to join this half demo half mumbling talk.


Building mostly serverless distributed cloud systems step by step [WORKSHOP]

Serverless is definitely here to stay, and there are also more and more frameworks meant to ease serverless containers and functions development (even across clouds) becoming stable every day.
Although the idea behind serverless is not to worry about the infrastructure, you still need to worry about how long will it take to scale, and that's where things like cold starts, preheating, multiple deployments, and hybrid environments come into play.
Basically, serverless is a great tool when used where needed, and that's the topic of this talk - learn how to build a serverless system, talk about some caveats, and discuss alternatives.

At the core of the system, we'll take a third-party system and pretend it's a legacy API, and then slowly build our distributed, scalable, geo-distributed and a tad cross-cloud system around it.

Containers will be used for tasks that take time, and some places where we need an immediate response. Durable Functions will be orchestrating the whole logic. We shouldn't forget about Service Bus Queues/Topics, but we'll also need Event Grid to connect various parts of the system. In the end, there's "nothing better" than API Management to be at the front.


Business Values of Going "Serverless"

Fact 1 - developers love shiny new tools
Fact 2 - proper adoption of new technologies on a project or in a team takes time and money
Fact 3 - most technologies that stick around, stick around because they are bringing in more value than their predecessors

So how do we know when is the right time to go serverless?
Serverless aren't only functions - serverless are also containers, auxiliary services, services which glue your system together, as well as a mindset.
Also, functions aren't only serverless - you can run them on-prem if you will.

Containers nowadays have a critical mass behind them, regardless of them being hosted on-prem, on a VM in the cloud or on a serverless cloud infrastructure.
So the first thing we need to answer is what the business values of developing functions are. But we also need to address what are the downsides.

Only after we've absolved functions can we really start talking about business values which serverless brings, both short term and long term, but we shouldn't do it without mentioning all the pitfalls possibly waiting on that journey.

So, to give you a hint - the answer is, as always, "it depends".

But the very first thing to discuss here is the massive value that teams get by moving to the cloud because all of a sudden a small team or even a single person can set up and develop anything from simple "Hello World" examples to complex distributed systems spread around continents. And all of that can be done without a massive team taking care of servers or planning their deployments.

Now, let's find out which parameters are important for your business success on the serverless journey.


Serverless Beyond Tutorials

There's a huge hype around serverless and the idea that the only thing you need to do is write some business logic code.
There are a lot of cases where this is true, especially if you're using serverless for background jobs without much concern when it will finish processing.
Unfortunately, there are still a lot of cases where things aren't so peachy, where you still need to worry about latency, performance, and scaling.

We'll start with discussing the granularity of your functions, and their "distribution" among multiple functions apps/deployments you might have, as well as options and latencies in connecting them.
Naturally, we'll also see the impact of huge libraries on cold starts, and general performance.

Monitoring your code has always been important, but it becomes crucial once you start using functions, especially when your workflow is jumping between multiple serverless instances, a bit of VM Scaled Sets in the cloud, and a tad of machines on-prem.

Cold starts are the arch enemy of performant serverless functions, but there are ways to tame them. We'll discuss and demo preheating solutions, DIY hybrid deployments, and a new hybrid solution on Azure.

The "only" remaining problem is scaling. Although the news says you can get the resources you need when you need them without ever thinking about the underlying infrastructure, that's not really true.
When we're confronted with scaling limitations the "simplest" thing we can do is multi-deploy our functions apps, which brings some other concerns like provisioning all those function apps, connecting them to CI/CD, and making sure you can load balance between them.

In the end, a problem ignored by the most is versioning. In most cases, there is no problem, but once you go multi-deploying your functions, and have deployments while there is some load on your system, you might produce a lot of problems if you're not careful.

Come, join, and enjoy a mixture of experiences from the Azure trenches and useful demos.


Past and future events

MiXiT 2019

22 May 2019 - 23 May 2019
Lyon, Auvergne-Rhône-Alpes, France

Azure Saturday 2019

16 May 2019 - 17 May 2019
Munich, Bavaria, Germany

MVPDays Azure Day Online

15 May 2019
Calgary, Alberta, Canada

Weblica 2019

10 May 2019
Čakovec, Međimurska, Croatia

Global Azure Bootcamp 2019: Glasgow

27 Apr 2019
Glasgow, Scotland, United Kingdom

Global Azure Bootcamp 2019. Developers Edition - Križevci

26 Apr 2019
Križevci, Koprivničko-Križevačka, Croatia

MVPDays Online January 2019

30 Jan 2019
Calgary, Alberta, Canada

Advanced Technology Days 14

4 Dec 2018 - 5 Dec 2018
Zagreb, City of Zagreb, Croatia

CrisCon konferencija 2018.

21 Sep 2018
Križevci, Koprivničko-Križevačka, Croatia

KulenDayz 2018

30 Aug 2018 - 1 Sep 2018
Osijek, Osječko-Baranjska, Croatia

Weblica 2018

11 May 2018
Čakovec, Međimurska, Croatia