>> Hello, everyone. My name is uriko, i'm here as
Representative of honeywell and i'm here today to tell you how
We have migrated our smart thermostat cloud solution to
Service fabric. First, let me say few words
About honeywell itself. Honeywell is one of the fortune
100 Companies. We operate in be 70 countries
And have more than 131,000 employees worldwide.
We are making lot of cool stuff, both digital and physical, and
Our business goes from smart homes to cool factories to
Aerospace and the division i'm part of has its products
Installed in more than 151 million homes and more than 10
Millionly buildings worldwide. I have experience for developing
Cloud solutions for cloud devices. Smart cloud, what can you
Imagine under this? basically, it's a cloud solution
That provides three main capabilities, device management, downloading processing and
Command and control. What can you imagine under each
Of those bullets? device management from
Associating the device with a customer to firm wear upgrade
Over the aircrafts all standard stuff, processing, mostly
Receiving and caching data from devices to be able to
Quickly serve our commerce to receive
Status of their device over the internet and command and
Control, control of your device over the internet.
Typical scenario, you are leaving work early and it's
Middle of the winter and you have your thermostat set up in
Your schedule that it's keeping your house cold to save money,
But you want to have your house warm when you get home so before
Leaving work you will just open our application in the
Smartphone, change the set point and wala, when you return home,
Temperature it as you desire it. Or you can use our geo feature
And let the location feature on your phone decide when you are
Close enough home to actually increase temperature.
Also because of the telemetry processing in the cloud we can
Make enhancements on changing firm wear on the devices
Themselves. For example, we can provide
Customers with capabilities that if temperature crosses threshold
We can notify them over notification via email.
What helped us when we migrated to service fabric.
One advantage that was visible instantly was price reduction
Because of service fabric and the way how it aggregates
Services on single machines you are able to reduce number of
Virtual machines in our solution, thus
Reducing costs. Speed, thanks to the framework
To store data off our thermostats and by using that we
Achieved tremendous speed, 99.9 Of calls that are requesting
Data in our system is faster than 50 milliseconds.
Ultimately deployments without downtime that's one of the
Greatest features of service fabric it allows you to do all
This around your life cycle management and upgrading
Application is now very easy even with fall back option when
Something goes wrong. Adding machines helps easily to
Scale out and it's true, microsoft solution, we can
Integrate new services for new requests very easily.
Where we started. Our second generation thermostat
Cloud it was second generation but it was natively built for
Azure and it was based on cloud services and azure service
Management because nothing else was available at the time.
We used orleans to store our thermostat data, and now it's
Open source and you can see their sources on github and the
Whole solution was designed with service fabric in mind because
Our friends in microsoft who helped us to design this
Solution told us that there is something coming and we should
Be prepared for it. They also helped us to prepare,
Saying what we should avoid to be able to easily migrate toward
Service fabric. So the migration later on was
Much easier. Challenges we saw with cloud
Services. Mostly it was extremely costly
Because of reliability having to include and introduce new vms
Just to be reliable. For example, we ended up with
Three machines running on api who have
Utilization of certain people all the time.
If you want to introduce cloud services you have to introduce
Your own, introducing new vms, you have to pay for that and
Secure service manager is not -- azure service manager is not
Easy to automate. You can automate it, there is no
Problem around that but achieving behavior that azure
Resource manager provides by default like
Deployments, it would require code that you have
To write yourself so we decided it's not worth effort.
And one tiny problem that has proven to be quite big over the
Time, we wanted to honor idea of compile once, deploy everywhere
And it's not easily possible with cloud services because when
You create cloud services deployment package, it means
Testing environments have to be scaled as production at least in
The vm side. You, of course, can have smaller
Number of instances but you have to have the big vms as you have
On your production. So when service fabric finally
Came out, we decided to redo the system to do an upgrade and move
Our solution toward service fabric. During that time frame we also
Decided to do few other investments, few other pieces of
Work that was, a, recommended to us by our friends at microsoft
Or they were things that we learned the hard way over the
Time when we are running our cloud services solution.
Mainly what we have done during the migration, reported all
Applicable services to service fabric, almost every single
Service with only one exception and we decided in our investment
To rewrite all apis to sp dot
Core, because development and performance, everything is
Happening in the sp net core world not in the
Sp dot net. We achieved the data locally and
The speed i was talking about and also because
Azure resource manager was involved we decided
To do automation, and automated everything as much as possible to achieve one-click
Deployments. The process of migration, over
All it was very smooth. We haven't hit any hard issues
We couldn't solve. We haven't had to change the
Logic of our applications. That was very helpful and helped
Us very much. Only thing we have to somehow
Rewrite a little bit but that wasn't that hard was our
Thermostat thermostat information that
Is now in the steady state.
There were a few things we had to work on but to be honest most
Of those you won't meet today because they were more of like
Price we made because we are using few things that were just
Freshly available or even in preview.
One of the things, lack of azure resource manager recommendation.
It improved a lot over the last year.
In our case it meant that we had to reverse engineer few things
When we were writing and creating our infrastructure templates.
Sp dot net core tooling and preview. That was one of the hardest
Issues let's say because the tooling with 2015 was hard to
Work with, it had few issues we had to overcome and overall it
Was painful to get everything working.
One of the main challenges, let's say, was that service
Fabric requires you to compile your projects in
64-Byte platform, and to get those
Working together you have to work around it a little bit
Napped to be friends between those projects.
Also we have subtle differences between orleans api and sector
Apis but those were small and tiny differences.
I can from top of my head remember just one, remember we
Had because we were disposing timers improperly but to fix was
Really easy and since then we haven't had any issue.
Also because of the different hosting portal that service
Fabric provides we have to work a lot on different monitoring
Tools and different monitoring requirements.
Previously it was very easy, one machine was hosting single
Process, single service. Now we have to be prepared that
Our services are running together on one machine, there
Is multiple process running. I will say to scratch just the
Surface is all we have time for, please go to our website, there
Is work we have written along with microsoft that uncovers the
Story of our migration. Please read it and full have any
Questions, any comments, i will be standing next to the service
Fabric booth for some time so please stop by and ask any
Questions if you have any. Thank you very much and please