SASE is not just another Remote Access VPN
Oh, Mister; you're so SASEy
Call it Secure Access Service Edge (SASE); call it Zero Trust Network Architecture (ZTNA); hell, even call it the Service Edge (U2 would be proud); but you might be forgiven for thinking talk about VPN is all over at the moment, and for asking why everyone is Cloudwashing what you've know as Remote Access VPN for many years. The answer, bluntly, is they aren't; the modern Business Application Landscape has vastly changed, and Remote Access needs to change with it.
The time was all your Business Applications would be on-Premises (on-prem), and you'd need to sometimes infrequently allow employees to access these from home. Let's say you're a typical Enterprise shop, with:
- A few on-prem Data Centres from various UK Managed Services Providers (MSPs), or even Colocation (Colo) Providers
- A few thousand employees scattered across the UK
- A hundred or so Business Applications
- A few Internet Gateway Data Centres with Web Proxies, Reverse Proxies and some diverse Direct Internet Access (DIA) connectivity
- Two hundred or so Branch/Office Locations across various UK Towns, Cities and the odd Factory/out-of-town Location
- Dipping your foot into Public Cloud Providers such as Amazon AWS, Microsoft Azure and Google Cloud (GCP)
Maybe your Environment looks a little like this:
Current Mode of Operation (CMO)
Most of your Users are in the Office most of the time; when they need to, they'll use their VendorCo VPN Client to dial-in to https://vpn.yourco.com which will non-deterministically Load Balance between the Manchester VPN Concentrator and the London VPN Concentrator, regardless of where the User is geographically located ("Look, it was too hard to explain to the MSP what Anycast DNS is, OK?"). Their Productivity files (Word Documents; Excel Spreadsheets; etc) are mostly still on-prem, and located on File Servers in their Usual Office Locations; pretty much all the other 80% of the Business Support System (BSS)/Business Applications they need to perform their roles are also in your BSS Data Centres.
You're currently running some Proof of Concept (PoC) work in the Public Cloud/Cloud Service Providers (CSPs), but you're not too sure if this will really take off in Big Enterprise or suit your needs. Most of your Business Apps have a good heritage and come from a time before React/Vue/Node Javascript Frameworks existed, or before it was thought that a Web UI could be used for anything useful; so you've got lots of Fat Clients, Oracle and IBM Middleware Layers, and people generally accept that your ERP Application looks like someone threw up with a paint can, and flunked out of Data Input Class in College ("Checkboxes? Dropdowns? Multi-selects? Has this Vendor never heard of Input Validation!").
You've got Forward (Web) Proxies because Facebook won't read itself (and you have some legitimate Web Applications your Employees need to get to). You've got Reverse Proxies because you have some Applications which, while hosted in your BSS/Backend Data Centres (that aren't natively setup to be Internet-accessible), over the years you've found Suppliers, Systems Integrators (SIs) and Partners all need access to them; sadly these Apps don't generally have a notion of an API, so you've had to setup a Reverse Proxy or two in your Internet Gateway Data Centre to allow inbound Internet Access to them from other Systems (M2M).
Most of your Staff think the Remote Access VPN is clunky, slow, and cumbersome to launch ("Ever noticed http://internal-intranet doesn't load on the VPN if you left Internet Explorer open before you took your Laptop home for the day, off the VPN?"), but they rarely use it, so they'll tolerate the issues it poses. You think it's secure because you've only got two entry points into your Castle from the nice Internet Gateway moat.
COVID-19 Mode of Operation
Most of your Users are now firmly Working from Home (WFH), and are struggling to use your Remote Access VPN because:
- It doesn't have the bandwidth
- It's slow to load (your Scottish Users are going via London; your Watford Users are going via Manchester; you lament not putting in Anycast DNS or Geo-based DNS GSLB)
- It's backhauling everything through two overloaded Internet Gateways (which have their DIA and MPLS pipes in a constant state of "on fire", in terms of Network Capacity Utilisation)
- It's not allowed through half the MSP Firewalls/ACLs you have on your on-prem Environment ("I thought the VPN was 10.99.0.0/24; when did they change it to 10.98.0.0/23 on us? It'll take weeks to raise these ITIL Firewall Change Requests with MSPCo to get it done!")
- Your lesser-Technical Staff don't realise they have to enable it to access some on-prem Applications, and disable it to access the Applications you've quickly lift-shifted to Public Cloud
In short, it's not really working out for you. But can you blame it? Remote Access SSL/IPsec VPN comes from an era before Cloud Distributed Computing existed; it's a Moat expecting there to be a Castle everything is inside. Ditto, because the Applications of it's era operated at the lower levels of the OSI Model, it needs to give your Client a Network-level (Layer 3) IP Address, and effectively act as an extension of your Corporate WAN "just in case" the Business Application in question needs that functionality to work.
It's a Solution no longer fit for a 2020's Problem (Public Cloud, Commodified Applications and Geo-distributed Workloads).
Future Mode of Operation (FMO)
Let's level-set a bit - you are still a Big Enterprise, so Digital Transformation isn't quick, and you've still got Legacy/on-prem Workloads like Mainframes that can't move to the Public Cloud for lots of sensible financial and business reasons. However, now you've started to (more aggressively than you'd like to, thanks to Coronavirus):
- Move Commodified Applications (i.e. all the Apps that were never specific to YourCo PLC in the first place - Collaboration, Document Hosting, ERP and CRM, etc) to the Public Cloud
- Typically, as a Software as a Service (SaaS) offering (in which case it may as well not exist to your WAN/Public Internet; "You only need a Web Browser and Internet Connection to access it")
- Sometimes, as something cobbled together with a hybrid of SaaS and Platform as a Service (PaaS) because of a niche workload requirement you have (but it's still likely to bias for at least the Frontdoor of the App to be "Just access with your Web Browser and Internet", even if the Backend/M2M interaction doesn't)
- Deploy SASE Connectors (i.e. Zscaler ZPA Connectors) as-close to the Applications as possible, and in multiples (unlike the SSL-VPN Concentrators you only had a few of)
- Deploy SASE Connectors into your ROBO/Branch Offices
- Deploy SASE Connectors (or accept the native-Internet Frontdoor-into) your Public Cloud-hosted Apps
You've come to terms that most of your Staff work well Remotely, and that the "fulltime return to Office, Mon-Fri, 9-5" is unlikely to happen (and probably benefited hugely productivity-wise from their lack of commuting fatigue). Your staff are much happier using the SASE (i.e. Zscaler, Cato Networks, Cloudflare, Proofpoint), and unexpectedly your DIA and MPLS pipes are actually quieter because of this.
Your Security Posture has improved and you've found that you have less attempted-Malware/Worms/Viruses but you're not too sure why. You also find that Users report the same Legacy Applications (that you've not touched since pre-COVID) are more performant when they're at home than on the Remote Access VPN Prior.
So what's the big change that's happened then? Why are most things much better, it's just SSL-VPN Tunnels, right?
SASE is not an OSI Layer 3 Network Extender
To understand the performance and security gains that a SASE/ZTNA brings to the table, we need to compare what a SASE is doing versus what a traditional Remote Access VPN is doing. It's perhaps easier to see this in a comparable format:
| Remote Access VPN | SASE | |
|---|---|---|
| OSI Operating Layer | Layer 3 (IP) "Barry's Laptop is 10.98.99.1/23 from VPN Range..." |
Layer 4 (TCP/UDP) "Barry's Laptop just looks like the SASE Concentrator at 10.10.3.2/24" |
| Geo-Load Balancing | None "Claire is in Scotland but came in via the London VPN Concentrator?" |
Yes (DNS GSLB or Anycast DNS) "Claire is in Scotland, so went to the SASE Provider's Scolocate DC-hosted SASE Control Server" |
| Security Granularity | Course "We need to allow the whole 10.98.0.0/23 VPN Range access to BusinessApp123" |
Grain "Bobby from Finance can access BusinessApp123; nobody else is allowed" |
| Tunnel Behaviour |
Always-On/All-Traffic |
Ad-Hoc/Split-Tunnel "Janet only goes via the SASE Tunnel for on-prem/defined Applications" |
| Activity Logging | Minimal (if any) "I've no idea what Patrick was trying to access via the VPN at 12:52 last Tuesday" |
Holistic "Patrick was trying to get to ServerName123 via TCP/456 at 12:52, but the TCP Session never went past SYN-ACK" |
| Tunnel Initiation | Singular, User-to-VPN Concentrator "I see the SSL-VPN Tunnel from Nicole on TalkTalk into our London DC" |
Multiple, SASE Connector to SASE Cloud "Regardless of nobody being logged in, the SASE Connector in Colo DC #3 auto-dials-out to SASE.com Control Plane Cloud" |
| Day 0 Complexity | Low "We just route through/allow in ACL 10.98.0.0/23 VPN Range, and away we go!" |
High "But I don't know all the Apps I have or TCP/UDP Ports that make up those Apps!" |
| Tunnel Flow | (Tun1) User -[Internet]-> VPN Concentrator "One SSL Tunnel, from a VPN User to a VPN Concentrator" |
(Tun1) User -[Internet]-> SASE Cloud (Tun2) SASE Cloud -[Internet]-> SASE Connector "SASE Provider has a Cloud LAN that stitches these two SSL Tunnels together for the end-to-end flow" |
| ROBO Tunnel | ROBO Branch -[Internet]-> VPN Concentrator "ROBO Users always hairpin via our Internet Gateway-hosted VPN Concentrator, using our Internet Gateway DC's DIA bandwidth" |
ROBO Branch -[Internet]-> SASE Cloud "ROBO Users only use our Internet Gateway DC DIA bandwidth when communicating with on-prem Offices; ROBO-WFH End User stays on SASE Internet" |
By far and away the main difference in the SASE model is that of the Cloud-based LAN, where the Cloud-based LAN is the "magic" that stitches together multiple SSL Tunnels, to allow the solution to efficiently only use the SSL Tunnels required for a given end-to-end flow, rather than having to "waste" Internet Gateway DIA/MPLS bandwidth for a flow that may not be to/from an on-prem System or Location. This is also what provides the main benefits of SASE over Remote Access VPN as highlighted above, as the Cloud-based LAN acts as the "Piggy in the Middle" (MITM) to any given Application Flow, and therefore can enforce Security, Bandwidth and other controls at higher-levels of the OSI Model than a Layer 3-constrained Remote Access VPN is able to do.
When compared to the Business Application world, which is doing mostly the same thing (the Cloud is the "world's Computer", and has multiple attachment points/PoPs that are regionally close to the User as the centre of the Universe; not focussed on the App as the centre of the Universe), SASE can be seen as a better fit; in much the same way the Public Cloud uses Global Points of Presence (PoPs) as a mechanism to lessen the latency of an Application, and serve it as close to the User as possible, so too does a SASE use the closest "VPN Concentrator" to a given User. The OpEx-driven model allows a SASE Provider to do this cost-effectively for you as a singular Customer; whereas trying to build your own "Globe-spanning Cloud LAN" would cost significantly more outlay than you may be able to afford; hence using the SASE Provider's reach and expertise can only ever make sense over a more cumbersome Remote Access VPN.
SASE is doing to the Enterprise WAN what SD-WAN did to the Enterprise MPLS Network; or the Enterprise MPLS Network did the Enterprise Leased Line Mesh that preceded it; abstracting away point-to-point SSL Tunnels into a Fabric of dynamically-run, point-to-multipoint SSL Tunnel Flows that are created and destroyed on-demand
On the death of the Corporate WAN Strategy Moat
When the Castle's gone, the lay of the Land looks different
In the recent past, the way IT generally worked could be compared more to a that of a Feudal System from the Middle Ages constructing a castle than to the current situation we find ourselves in mid-pandemic. Previously what we built, and have done so since the late nineties, looked something like:
- Build a Corporate WAN out of MPLS, Leased Lines and IPsec VPNs (the "Castle")
- Build some Firewalls, IDS and IPS around it (the "Moat")
- Build an isolated VPN Concentrator into this for the rare times your Serfs needed Remote Access (the "Drawbridge")
- Host all your important Websites and Apps from within it, using Reverse Proxies and the like (the "Battlements")
- Force people to work in Office and Branch Environments, using certain tools, in a prescriptive way (the "Feudal System")
- Conform to the whims of the Architecture and Strategy Departments when modifying this (the "King")
I could probably go on, a lifetime spent in IT is indeed a lifetime learning to analogise; and in some ways, there truly is nothing new under the sun, just reimagining of concepts and events that have already occurred; but that's a blog post for another day. The point I'm trying to make here is that, much as in the fall of the Middle Ages, it takes factors outside of the current system to change into a new one; and that's where we believe the IT and associated Networking and Telco fields are currently at - the divergence of a new "age" of working, if you will.
The Cloud Era was too early
To understand this a bit more, lets step back a bit more in recent times than historical ones - to the beginnings of the Cloud Era, or around 2006-2009, when notably:
- 2006 - Amazon Web Services (AWS) launches with three Infrastructure as a Service (IaaS) offerings - Amazon S3 Storage, Amazon SQS Messaging and Amazon EC2 Compute
- 2008 - Google App Engine launches (the beginnings of a Google Cloud Platform, GCP)
- 2010 - "Windows" Azure launches (but doesn't yet really know what it is, or wants to do)
For most Enterprises ("Big E") and Small to Medium-size Businesses (SME/SMB), these aren't too relevant; probably roughly where we were a few years ago with Enterprise adoption, or "pondering" over Kubernetes and Containers - at worst, they are background noise; at best, a few people maybe dip their toe in and deploy some throwaway Proof of Concept (PoC) into bits of them. Nobody is really calling these out and differentiating based on terms like IaaS vs PaaS vs SaaS yet, as we're not thinking in an Cloudy mode; heck, "Cloud" isn't really a term that resonates with anyone at this point - apart from on TV Weather Broadcasts. Indeed, nobody really uses or understands the terms "On-Premises" and "Off-Premises" at this point, because there isn't really a world outside the Castle (the "On-Premises") anyway; when you live in a Castle, there isn't really a word for the outside world or alternative, because it doesn't enter your consciousness.
For context, let's look at the on-premises landscape during this same time period, where we're dabbling with:
- 2009 - Fibre Channel over Ethernet (FCoE) drafted and begins to be adopted by some vendors, such as the Cisco N5596UP in 2011
- 2012 - VMware ESXi 5.1 released and adoption of the concept of Virtual Machines becomes more prevalent in "Big E"
- 2013 - Cisco Prime LMS (which replaced CiscoWorks NMS) now becomes Cisco Prime Infrastructure, to consolidate the previously-separate Cisco LMS LAN/WAN Network Management and Cisco WCS WLAN Network Management product lines
What really stands out here is that, roughly during the time of the advent of Cloud, the rest of the world is focussing on one sole thing - convergence (of concepts and tooling that already exists). We're so busy dealing with multiple siloes of Infrastructure (that was the big point of FCoE vs FC + IP/Ethernet, it just never really got widespread traction), and trying to simplify the management of the then current state-of-the-art that we're not looking outside the Castle Walls. From our earlier Feudal System analogy, we're playing an introverted Game of Thrones inside the Castle Walls - some Barons will win (FCoE, for a very short time period); some Lords will lose (notion of one Physical Server per App) - but none of us are interested in what the world outside our Moat looks like, nor too much what the next Castle across the way is doing (maybe they never bothered to do FCoE, and jumped straight to iSCSI/NFS).
Shadow IT begins
Meanwhile, outside the Castle Walls, the Cloud Service Providers (CSPs) are getting their act together, and have realised that to break through they need to focus on the same person the IT Department serves - the End User - rather than just acting as an enabler for the IT Department itself. We're nearing the end of the Middle Ages, the weaponry is much better, and people no longer need to care for the whims of the King; they're leaving the Castle Walls, and building Settlements and Cities beyond the Castle Wall - beyond the (direct) influence of the King. Those Serfs, like our End Users, are doing this for much the same reasons - the Feudal System, within the Castle Walls, isn't serving their interests any more; they want more than to just abide by the rules of, and in the interests of, the King.
It's notable that now, things are fast-changing; a 2014 Release of the O'Reilly "Google Compute Engine" Book barely mentions any other Google Cloud Service, because few existed at it's release; not too long afterwards, rather than the thinking being "Cloud is just Compute", we exit the macrocosm of the this thinking, and create terms to describe other offerings that Cloud can fulfil:
- IaaS (Infrastructure as a Service)
- PaaS (Platform as a Service)
- SaaS (Software as a Service)
Now we have a compass and framework to categorise - and more importantly, to understand and consume against, we start to see the "Shadow IT" trend begin; it's good to note the negative undertone to this statement is because it's the IT Department that coins this term, and it's chiefly a negative one because the IT Department, much like the King, knows the significance of the pull of the Castle Walls are coming to an end; if you ask the Serf how they fell about life outside the Castle Walls, it's more likely to be a positive term they'll use - not so much for the King at the fall of his dominance.
People run off, and much like Devolution within politics, effectively start doing their own thing - for mostly no reason other than just because they can now do their own thing - well kind of, but then they hit the brick wall the Castle had already solved: centralised control.
SAML becomes the fiat currency
If we go back within the Castle Walls, the currency you use to transact goods and services isn't fiat (Government-backed); and it doesn't really matter too much, as you're stuck within the confines of the Castle Walls anyway; if your Castle uses Guineas and the Castle over the road uses Florins, it doesn't matter to you, unless you have the privilege to both leave your Castle and enter theirs. If you're the King, however, it probably does matter to you, and keeping peaceful relations with your neighbouring counterpart. Stepping back into IT, it's not a true analogy to say we've got one "King", even within the times of the Castle - we all know IT is a silo of siloes, so we've probably got:
- Microsoft Active Directory (AD) for universal End User Identity Management
- It's likely everyone from the Janitor to the CEO has an AD Account, "just in case"
- Oracle Access Manager (OAM) for certain End User Identity Management
- It's unlikely John from Engineering Division has an OAM Account as well; it's more likely Jane from Finance has the unfortunate "fun" of having an OAM login as well as her AD login
We've probably cobbled together some OAM-to-AD bridge, or worse-yet just used the same 8-character Username for both OAM and AD logins and told people to use differing passwords for both; but if we don't, we can kind of lie to ourselves and consider it a Single Sign On (SSO) solution. Maybe. Anyway, we've got a fiat currency here - the AD Account. But it's only fiat within our Castle Walls; if we do a Merger or Acquisition, this becomes blatantly clear that our AD Florins do not match in value to the other Company's AD Guineas, and we go through some kind of painful process you might enliken to the introduction of the European Single Currency.
Shadow IT, however, breaks this; we're not in control of the SaaS or PaaS, or cobbled-together App the End User has created, and it's outside our Castle Walls anyway - so it might not honour the inner-Castle currency of our AD install. We as the IT Department would still like some control though, and the End User is now sick of doing all the boring moves-adds-changes and CRUD/ACID-like management - much like the Feudal Castles, we need a Bank of England to aribter between the disparate fiats. We need SSO. We need SAML.
Monarchy and the Republic
Security Assertion Markup Language (SAML)/SSO is a fantastic response to the IT Department at the death of the Castle; if we follow the principles of SaaS/PaaS well, we can use SAML/SSO to do our part in the devolved xaaS/Cloudy world - we can disaggregate some of the functionalities we'd previously have mandated (Compute/Platform/Storage/Network), and impart the skills we have honed over many, many years (CRUD/ACID/Security/Account Management) to best-advantage for the supposed "Shadow IT" our End Users have procured; we can enact power, influence and security over something we're happy is devolved to someone else. Indeed, it's telling that it's taken until fairly recent times for the likes of my logins to Cisco, Juniper, BT and so on to start using some form of SSO - just as "Big E" struggles with the journey, so too do "our" IT/ISP Providers struggle with the same "in house, everything is AD, those are the rules" versus "we enable via SAML, you do the rest" struggles; the current "Big E" version of the monolith versus microservice debate, if you will.
Wrapping back to Strategy, the important thing that SAML/SSO allows us to do is exert our best skillsets in the interest of End Users; prior to more-widespread adoption of SSO, the narrative ran that "Cloud will take our jobs!" and prior to that, the narrative ran that "Cloud is just someone else's Computer anyway!". But as our understanding and maturity evolves, so too does our understanding that there are some areas of specialism and complexity that it doesn't serve us well to even try and do - as AWS' Werner Vogels often states, there is little point in undertaking "undifferentiated heavy lifting" of aspects, skills or specialisms that we, as a larger Enterprise or Company, don't have - and frankly isn't one of our core competences. Much like many workplaces outsource the cafeteria to an outside concern that specialises in food preparation; why should we be concerned if an End User consumes WidgitCo Ltd's SaaS that does the job they need - as long as we can still exert some influence and control on the use of this, via a technology such as SAML or SSO.
In some ways, this is similar to the concept of Monarchy and Government, each acting as a balance to the other - but each far-enough removed from the daily running of the other so as to not interfere and conflict. Really, this is where "IT Strategy" needs to go - we need to care less about exerting direct control and management over the Compute/Storage/Networking building blocks, and step back and consider what the End User intent is, and why the lower elements of the stack need to exist to service the End User's needs.
ZTNA to the Future
Allow me to take my Enterprise Architecture hat off for a second, and apply this to the area I'm more au fait with - Network Engineering. In our world, Remote Access ("Dial-in VPN") has looked relatively samey in the past forever years:
- Nail up a Direct Internet Access (DIA) or two into the Enterprise WAN at various Office or Data Centre Points of Presence (PoPs)
- Implement a big ol' stack of expensive "Black Magic" Security Boxen (IDS/IPS/Firewall/<list goes on>)
- Implement a number of fleets of IPsec or SSL-VPN Concentrator Boxes
- Allocate the End User an OSI Layer 3 Address (IP Address) to connect them into the Network
- Implement a whole bag of distributed Access Control Lists (ACLs) and related to undo the Network-wide L3 Access we just gave them
Much like those who believed the earth was flat, before anyone had any chance to explore - or feedback through stories thereof - in yesteryear, this looks fine if it's what you're used to, and you're too busy doing other things to question it (a life in Network Engineering is one spent atoning - with time and suffering - for your alter ego's sins, I'm sure). However, it takes a change in perspective to make you realise the daftness of this model - step in Zero Trust Network Architecture (ZTNA), where instead we:
- (Either) Nail up a Direct Internet Access (DIA) or two into the Enterprise WAN at various Office or Data Centre Points of Presence (PoPs)
- (Or) Exploit our Cloud On-Ramps (Microsoft ExpressRoute/AWS Direct Connect/Oracle FastConnect/Google Cloud Interconnect) into the Enterprise WAN to act as PoPs
- Implement some virtualised "Black Magic" SASE Boxen
- SASE Boxen act at OSI Layer 4 and above, so End Users don't have an L3 Address (IP Address) that's natively on the network
- ...so we don't have to worry about ACLs and undoing the L3-wide access we (didn't) just give them
When you see this architecture, you quickly realise the floors of the former; why indeed would I give an End User complete L3-wide IPv4 Access to the Network, at the OSI Network Layer, when all they need are access to some Applications, which reside at the OSI Transport Layers and beyond? this is the SASE/Remote Access VPN-equivalent of using Stretch L2 VLANs in the Data Centre space "just in case it's ever needed"; a problem waiting for a solution.
Cloud and the role of Strategy
All of which is why the role of the "Strategy Department" needs to change it's thinking and remit from where it is today; the Castle's Walls are down, the Drawbridge is no longer the only way in; your edicts can't enforce ways of working on people; "Shadow IT" might not be as bad as you think, because chances are, we weren't doing the greatest job doing it to begin with. Much as in the concept of Devolution within politics, "with great power comes great responsibility" - and End Users are indeed learning from, and suffering because of, this very notion. Sure, they spun up some App somewhere and it was working fine, but now the adoption has grown to many more Users, and people are asking them questions about Compliance, and Remote Access and this "IP Addressing?" thing they don't know about has led to them appreciating, in some small respect, what the IT Department had to deal with.
Now is your time to either step up, and help them out - which is really what the concept of Strategy is all about (imparted learnings onto the masses, based on prior expertise) - or sneer loudly at them, which has two chief negative byproducts:
- They'll not like you for it (and likely go off and do the same thing again, with something else, if only to spite you)
- You'll have no role left to fulfil (if they've got the power due to xaaS and you're not helping, "why" are you still in existence?)
If this resonates with you, I'd suggest now would be the time to "Cloudify" your thinking and go with the flow, and use your knowledge and expertise for the good of everyone, and act less as a dictator of how to build low-level Compute/Storage/Network stacks, and more as an advocator for how to best-utilise the "Global Computer" that is Cloud and xaaS. Your role is no longer to tell people the exact model of car to drive; it's to educate them in how best to drive and maintain whatever they choose.
Otherwise, I can tell you about what happened to the Jester in the Court from the Middle Ages...
A warm welcome to the Cloudnibble blog
Welcome, welcome, one and all!
A warm welcome to you, on this confusing year of 2020, to the first ever Cloudnibble Blog post. Here we hope to give you advice, strategy, thoughts and general musings on all things Cloud, Networking, Optical, Web Development and general Digital Transformation. As we specialise in being a boutique IT and Cloud Consultancy, we thought it might be worth putting some proof in our pudding, by covering topics and scenarios relevant to companies just like yours, such as:
- Secure Access Service Edge (SASE)
- Microservices vs Monoliths
- Service Mesh
- Cloud Networking
- Cloud Service Providers (CSPs)
- Software Defined Networking (SDN)
- Software Defined Data Centres (SDDC)
And many, many more areas that my specialist colleagues are more than happy to deep-dive on.
Benefits of the blogging format
One of the biggest benefits of a blog format is that we can have an open conversation with you, and mix and match some of our foundational learnings with snippets of information, perhaps such as a piece of relevant Cisco IOS command:
show ip bgp vpnv4 vrf BLAH summary
Or maybe with a direct quotation from someone else in the know, with an Industry angle that's pertinent to you:
You know because Gartner said it, it must be true!
Nobody is sure what will happen
Now perhaps more-so than ever, which is why we want to open up to you, and help your business in the increasingly digital-world, in whatever way we can.
If you've got a Networking, Cloud or Digital Transformation problem, reach out to our bespoke consultancy today, and let us get you on the way to improving, fixing or installing whatever digital aspect is currently ailing you.