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. 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. 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

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 stateful, resilient and complex serverless systems while orchestrating old-school stuff

Serverless functions are by definition stateless. Also, when they crash there's no „top function“ out-of-the-box that will notice it. Building complex workflows with them mean that you'll usually use a whole bunch of queues, and place logic that determines what's the next step inside of each function (where it shouldn't be), instead of in a central place.
Now enter Durable Task Framework and its Azure „implementation“ Azure Durable Functions.
They come with event-sourcing available out-of-the-box, meaning that all of a sudden your functions can remember state. Developing complex workflow is no different that awaiting for some Tasks in your „console C# app“, and chaining and error handling is built in.
So all of a sudden your serverless system start having simple, and clean code while being resilient.
Not only that, but you'll be able to call some non-functions services, place your function to sleep (which doesn't incur costs), and wake out once the external event URL has been triggered.
Enough said, let's build some live demos during this session 😉


Migrating LOB mobile apps to chatbots - why and how

In theory the „how“ part is easy. All you need to do is pick a bot framework, connect it to your communication channel of preference, design some conversation workflow, connect all of that to your existing API, and you're done.
Yeah... not if your LOB mobile app is actually a mobile app that drivers need to use while driving. All of a sudden the UX complexity skyrockets. When you only think about continuous real-time location sending, photos upload, and automatic verification of them, etc... functionalities skyrocket as well.
It's still doable and functional at the end, but come and hear how.
As for the why part... the short answer is that it's not a silver bullet, but it can decrease dev costs by a significant margin, as well as speed up dev time, and „new version“ adoption. Also, since there's a zillion apps out in the wild your users will thank you for not having to install yet another app.


Integrating the world using serverless

You've probably heard of BizTalk Server, and you might have an opinion about it 😊
My biggest issue with it is that it's something that you install on a (virtual) machine, and you can't just go and say „hey, I'm gonna need three of them for 5 minutes starting now“. Let alone the fact that someone needs to actually maintain that whole environment, and keep it safe and sound.
So here's a crazy idea – let's integrate „everything“ using serverless services on Azure.
When we'll want to use a GUI wizard to integrate something we can use Logic Apps. If we'll want to write some code, we can use Azure Functions (or in the worst case serverless containers). But, when we'll need to run more complex and longer tasks on serverless Durable Functions might be the best fit for us.
Naturally, we'll need to send messages and events between various services, and there's just nothing like Service Bus and Event Grid out there.
If you'll want to hear how a developer started integrating and automating whatever he can, please join 😊


Provisioning and deploying to serverless [WORKSHOP]

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.


Mobile DevOps & Remote Teams

CI/CD is only a small part of DevOps, and the biggest part is humans. Because of that, doing DevOps is hard. Doing Mobile DevOps is even harder because some steps take much longer than for example in the web frontend project, but doing Mobile DevOps with fully remote teams is an adventure.

After years of doing it, I like to think that I've identified and minimized major obstacles and time wasters which were causing delays both in planning and delivery, but there are still quite a few challenges lying ahead.

Not only that you need a way to organize your team spread around the world so that they don't block each other while maintaining the work-life balance they prefer, but since we're not in the same office debugging something on a specific mobile phone not physically available to a developer can be quite challenging until you solve it through a "standardized" process.
For years we've been talking about automated this, and automated that, but when doing mobile automated tests can really block or at least slow down your team, so it's really important to identify the places in the process where waiting for the results is a need, and where it is not.

Having strict code style/code commit policies can incur a lot of harm when your developer is working from a beach on Bali and keeps the whole code on his/her machine before it's all polished up. Water tends to get into those machines, and MacBooks are a nice target for thieves all around the world. Which kind of brings us to encryption, and quick deprecation of keys, connection strings, etc because failing to do so in the minimal amount of time can incur a lot of harm to the team and the client. So... since we're all geeks, we have a phone number which you can call and it triggers some cool scripts on Azure.

There's a lot more to discuss on making our life a joy while delivering even better and more robust products, but you'll have to join the talk to discover it...


Serverless + Chatbots == Silver Bullet for Startups?

Years ago I had a startup which failed because of two reasons. One was legal because the idea was to automate something up to a point where it becomes illegal in my part of the world because of prehistoric laws.
Sure, we could've pivoted, but there comes issue number two - we had no idea how to slim down the development to something which could be considered an MVP, so we went into an adventure of building a "proper" piece of software.

Years later, some of my clients are startups with proper funding, but I'm also mentoring some which are in their early days. And what I see is that almost everyone has a problem building an MVP.
Most of them spend too much time building too complex but patched up, software solutions that end up looking like s... which results in low adoption of users, especially when they want to build mobile apps.

On one hand development prices are through the roof today, and on the other hand, users are saturated with products so startups don't only have a tougher job of reaching the customer, but they also have less time to build and prove an MVP than 5-10 years ago.

There is an up point for them - they can allow themselves to build greenfield products without having to worry about any legacy systems compatibility.
Which means that they can leverage two fancy systems that are actually really useful and stable in 2019.

Queue in chatbots and serverless.
What chatbots can do for you is cut down the development time compared to building a mobile app, and improve your user adoption rates because all of a sudden the users now already have the app on their phones which is needed to use your product.
Serverless, known for their ability not only to scale massively but also to scale down to zero, allows startups to build scalable and distributed systems without much knowledge while keeping the cost down until they start having some heavy traffic.

After trying it on a few projects, it worked like a charm, but there are still some caveats so here comes a tale that might be much more than a fairy tale.


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.


The Art of Monitoring and Debugging Azure Functions

As if monitoring monoliths deployed on a single server wasn't hard enough, we're now trying to figure out what's going on with our systems constructed out of short living functions and containers spread all around the world.
This new "era" brings a lot of problems, and in a way sets us back 10-15 years.

First of all, we need a way to figure out a map of our system, otherwise, we won't know why some functions are being triggered, which will make it extremely hard to find and fix bugs, as well as introduce changes to workflows.
Second, although running and debugging a part of the system locally is always an option, sometimes it's not good enough. For those situations, we need to remotely connect our debuggers to a live system and/or take a snapshot.
Third, our logs will become huge, and we can't allow ourselves to start digging through them by hand, and try to connect which log entry connects to which one. That's why our distributed system needs a way to connect all those dots so that we can just query for everything connected to a certain operation.

If you've found at least a bit of yourself in these problems, come and see how we can sort them out and make our serverless journey an enjoyable one.


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.


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 ;)


Past and future events

MiXiT 2019

22 May 2019 - 23 May 2019
Lyon, France

Azure Saturday 2019

16 May 2019 - 17 May 2019
Munich, Germany

MVPDays Azure Day Online

15 May 2019 - 15 May 2019
Calgary, Canada

Weblica 2019

10 May 2019 - 10 May 2019
Čakovec, Croatia

Global Azure Bootcamp 2019: Glasgow

27 Apr 2019 - 27 Apr 2019
Glasgow, United Kingdom

Global Azure Bootcamp 2019. Developers Edition - Križevci

26 Apr 2019 - 26 Apr 2019
Križevci, Croatia

MVPDays Online January 2019

30 Jan 2019 - 30 Jan 2019
Calgary, Canada

Advanced Technology Days 14

4 Dec 2018 - 5 Dec 2018
Zagreb, Croatia

CrisCon konferencija 2018.

21 Sep 2018 - 21 Sep 2018
Križevci, Croatia

KulenDayz 2018

30 Aug 2018 - 1 Sep 2018
Osijek, Croatia

Weblica 2018

11 May 2018 - 11 May 2018
Čakovec, Croatia