This document discusses three approaches to integrating HubSpot with an accounting data reporting tool:
1) An on-premise solution requiring developer and IT skills for setup and ongoing maintenance
2) A cloud-based version reducing maintenance needs but still requiring software patching
3) A serverless architecture using AWS Lambda, SQS, and API Gateway requiring different skillsets for setup but providing easier ongoing management through automation
Beautiful Sapna Vip Call Girls Hauz Khas 9711199012 Call /Whatsapps
Moving "Something Simple" To The Cloud - What It Really Takes
1. Thinking of Moving “Something Simple“ to
Cloud? Here’s Roughly What It Takes
Or How we Went from On-Prem to the Cloud
Branislav Repček
Director of Sales Engineering
2. Case study of a project that integrates HubSpot with accounting data
Financial Reporting in HubSpot
3. Reporting and notifications for various events in HubSpot
Send notification emails and create reports when certain events happen – for
example, an invoice is created, deal is won etc.
HubSpot cannot create the reports we need
We need to use other tools to build and send the reports
HubSpot supports notifications via WebHooks
We can use WebHooks to call external REST API
Use Case
4. We’ll use CloverDX
Data management and data integration platform that can easily connect to all systems we need
to work with
Connectivity
CloverDX can publish REST API and that will be the target of the HubSpot WebHook
CloverDX can create Excel-based reports and send them via email
Implementation Idea
6. Version 1: On-premise
HubSpot notifies us via
WebHook calls.
Firewall will only let
HubSpot traffic go through.
CloverDX gets called directly, verifies
HubSpot call credentials and computes
the data it needs to produce the reports.
7. Skills required to set-up
🙂 Developer to build the integration
🙂 IT admin to provision the network, VM, email, …
Skills required to manage production
😟 Support team to manage the app
🙂 Developer to implement any changes
How Does It Impact the Team?
8. Hard to estimate
🙂 Hardware (VM) likely very cheap
😟 Unknown cost of maintenance (patching software etc.)
Costs in Production
9. Old-school architecture
😒 Must patch Linux on the box, all software (CloverDX, MySQL, …)
😒 If power or network go down in client’s office, the service is down as well
😒 If down, HubSpot notifications are lost
Security
☠ Compromised service may let attacker into client’s internal network
Thoughts on Version 1
Pain scale
11. Version 2: Let’s Run it in the Cloud
Firewall will filter out
requests that should not
get into the network.
CloverDX gets called directly, verifies
HubSpot call credentials and computes
the data it needs to produce the reports.
HubSpot notifies us via
WebHook calls.
12. Skills required to set-up
🙂 Developer to build the integration
🙂 IT admin to provision the cloud resources
Skills required to manage production
😟 Support team to manage the app
🙂 Developer to implement any changes
How Does It Impact the Team?
13. Hard to estimate
😐 Perpetual cost of cloud instances, easier to predict
Need to be smart about sizing!
😟 Unknown cost of maintenance (patching software etc.)
Pretty much the same as before, but in the cloud
Costs in Production
14. Better, but still quite painful
😒 Still must patch OS on the box, but now in the cloud
😒 If down, HubSpot notifications can get lost
Security
💀 Compromised service may let attacker into client’s HubSpot, not their network
Thoughts on Version 2
Pain scale
16. Version 3: Going Serverless
Firewall and API
Gateway are the
gatekeepers
protecting from
attacks and hiding
the actual API
endpoint.
Lambda validates the
requests to ensure
only our HubSpot
instance can send
notifications. It then
pushes the request
onto a queue.
SQS acts as a
buffer that
collects all
notifications and
protests us from
notification
volume spikes.
CloverDX processes the
notifications, performs
the required
computations and
produces various
reports when needed.
HubSpot sends
notifications via
WebHooks.
17. Much more complex architecture than the original one
But does a lot more than the original
Is it harder to manage?
Harder to set up maybe, but should be easier to run
Different skills needed
Where Did My Simple App Go?
18. Skills required to set-up
🙂 Developer to build the integration
🙂 IT admin to provision the cloud resources
More work needed here than before – multiple services require more experienced IT
Skills required to manage production
😟 Support team to manage the app
😎 Environments “manage themselves”
🙂 Developer to implement any changes
How Does It Impact the Team?
19. Much easier to estimate and plan for
😐 Perpetual cost of cloud instances, easier to predict
Need to be smart about sizing!
🙂 The only maintenance is development of the app itself
Environment should just work if set-up correctly
Update certificates when they expire, check logs
Software will “update itself”
Costs in Production
20. New programming pattern for robustness and scalability
🙂 Only keep CloverDX + code up to date
😎 OS, containers and all other services automatically updated
😎 Queue prevents data loss when the service is down and allows us to handle spikes
😟 Lock-in
Security
🙂 Attacker must compromise multiple services to access sensitive data
Only CloverDX instance has HubSpot credentials, those are stored in AWS Secrets Manager
Thoughts on Version 3
Pain scale
22. Not so fast!
Not every use case can be so nicely translated to cloud concepts
Cloud trades one set of skills for different set of skills
HW maintenance, Linux admin, … traded for “cloud expert”
Cloud trades convenience for money
Serverless tech tends to be a bit more expensive than similar “fixed” cloud instances
Let’s Move Everything to the Cloud
23. Serverless will push you towards “microservices”
Added complexity might not be what you want to support
Going Serverless
(Macro) Services Miniservices Microservices
Greater agility
Lower complexity, easier to run
24. www.cloverdx.com
About CloverDX Data Integration Platform
CloverDX is a data integration platform for designing, automating and operating data jobs at scale. We've engineered CloverDX to
solve complex data movement and transformation scenarios with a combination of visual IDE for data jobs, flexibility of coding and
extensible automation and orchestration features.
Thank you
hello@cloverdx.com
Editor's Notes
Describe the architecture here.
They had CloverDX developers, so no issue with resources for build. Same for IT admins. Provisioning a new VM does not require much effort and everything could be set-up on that VM, so no huge complexities around it were needed.
The support is a different thing though. Support was not too happy about getting another app to support. Especially one that requires quite a bit of work to maintain as we’ll discuss in a minute. There’s also the future code maintenance or changes, but that again did not cause any worries since it was not expected to require any significant investment in the future.
Support is not free and even internal resources have costs associated with them.
So let’s have a look at why support was not entirely happy with the application designed like this. The arch is kind of old-school…
Support will hate it – one more thing they need and it can be fairly high maintenance since it is exposed to the internet. So we’ll need to keep everything up to date (CloverDX, database backend, OS on the box, OS in the VM, …). This can add up pretty quickly…
The security is also not ideal since it may give the attacker the ability to stay inside the client’s network with all their inhouse apps and sensitive data.