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

Going Serverless on Azure EN

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 EN

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.


Making the Internet polite, and the architecture behind it EN HR

Whenever you allow your users to send any type of content, you're taking a risk that that content will either offend someone or at least be contrary to your rules & policies. We're mostly solving those types of problems by combining plain ignorance, automatic verifications against a dictionary of some sort, and a bunch of students who have the "honor" to go through the various content whole day long.

That's where Azure Cognitive Services come to the rescue (naturally, there are other vendors) by allowing us to easily, and automatically analyze text, photos, and videos and all of that in multiple languages. Naturally, the decision whether some content is passable or not is to be left to the rules & policies of each system, but the potential of getting the info about someone threating someone else, or someone being in a big depression is mesmerizing.

It's not a huge deal to implement those Azure services into your own system, but not everyone has time, and expertise to design, implement, and maintain a proper architecture that will keep the system running across regions, without ever blocking, nor crashing the primary system.
Because of that, when I've started pilot projects for a huge TV station, and a "social network" for kids the decision was to build a "wrapper" around Azures services, and instead of integrating everything into each system, I've actually built a "plug&play" SaaS/API that can be easily integrated.

This talk is about the architecture of the beforementioned SaaS/API. The ingredients for the recipe are a bit of Cognitive Services, a bit of containers, a bit of Functions (Durable and "normal"), a bit of Event Grid, some ServiceBus, some storage, and DB, combined with a tad of API Management and ML.
Come and see how to mix all those ingredients properly ;)


Making the Internet polite, and the architecture behind it EN HR

U svakom sustavu gdje korisniku omogućite slanje ikakvog sadržaja riskirate da će taj sadržaj ili nekoga uvrijediti ili u najmanju ruku biti suprotan pravilniku vašeg sustava. Rješenja tih problema obično dobivamo kombinacijom ignoriranja, automatske provjere u odnosu na neki rječnik te zapošljavanja studenata koji imaju čast pregledavati sadržaj po cijele dane.

Tu nastupaju Azure i Cognitive Services (naravno, postoje i drugi vendori) koji nam omogućavaju automatiziranu analizu teksta, slika i videa na više jezika. Naravno, odluka je li neki sadržaj dovoljno dobar/loš ostaje na vlasniku sustava, ali sam potencijal da dobijete informaciju kako netko nekome prijeti ili je netko u velikoj depresiji daje ogromne mogućnosti.

Implementirati ove sustave u svoj nije neka ogromna nauka, ali kako se ne da baš svima razmišljati o arhitekturi koja će pouzdano raditi i pritom biti dovoljno pristojna da ne zaguši glavni sustav, mudro bi bilo razviti „wrapper“ oko Azureovih proizvoda te ga pretvoriti u plug&play SaaS.

Ovo predavanje fokusira se na arhitekturu takvog sustava kojem je u „sredini“ Azureov servis. Da bi to postao proizvod trebalo je osim Cognitive Services Text Analysis i Content Moderator dodati Event Grid, Service Bus, malo orkestriranog serverlessa, malo storagea, malo baza, malo kontejnera, malo API Managementa, ali i malo machine learninga.

Kako je to izvedeno, povezano, ali i zašto su odabrani neki konkretni servisi nauštrb drugih dođite škicnuti na predavanje.


Building mostly serverless distributed cloud systems step by step EN

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 EN

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 EN

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 EN

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 EN

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] EN

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] EN

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 EN

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? EN

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" EN

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 EN

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 EN

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??? EN

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 EN

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.


DevSecOps for freelancers (and everyone else) EN

Security should be a crucial part of any development project, but we've somehow managed to continuously ignore it during the last 5-10 years in exchange for building stuff "faster"...
And now, now we have serious data breaches every other day, and we need to find a way to take security into account, without it hurting our "performance," and that's the real challenge.

The saying says "never say never", but from today's point of view we'll never be able to automate security checkups completely, but that doesn't mean that we can't automate that "role" up to a "good enough" level, which is so much more better than not having any security checkups at all.
This is particularly important for freelancers because they're usually all alone on a project, and if they're gonna start seriously considering security as part of their pipelines, it has to be a mostly automated process.

What we're gonna cover in this talk is how to start taking care of security in your development project by tweaking your current DevOps process. You do have one, don't you? 😛
We're gonna cover what can you completely offload to automation, on what can you just keep an eye on every now and then, and what parts still require you to do manual work. Naturally, we'll also cover which tools can you use... tools which won't break your bank 😉

C ya and let's make 2019 the year DevSecOps starts to get some serious traction 😉


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

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 EN

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 EN

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 EN

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 EN

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.


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