One thing we know for sure is that under CEO Satya Nadella, Microsoft — in both action and spirit — looks very little like the Windows Or Else empire from the days of Steve Ballmer. The latest move is Microsoft’s acquisition this week of Deis, a little-known San Francisco developer of open-source software that makes Kubernetes easier to use.
Deis, in its own words, “helps developers and operators build, deploy, manage, and scale their applications on top of Kubernetes.” We all want to do that.
Writing in an April 10, 2017 blog post, Scott Guthrie, executive vice president of Microsoft’s cloud and enterprise group, wrote “we’ve seen explosive growth in both interest and deployment of containerized workloads on Azure, and we’re committed to ensuring Azure is the best place to run them.” The post goes on to say, “Deis gives developers the means to vastly improve application agility, efficiency and reliability through their Kubernetes container management technologies.” Guthrie We expects the technology to make it easier for customers to work with existing Microsoft container technologies, including Linux and Windows Server Containers, Hyper-V Containers, and Azure Container Service, “no matter what tools they choose to use.”
Deis CTO Gabriel Monroy, perhaps put it best, saying “robust and open container orchestration, paired with new application architectures are giving organizations unprecedented flexibility and choice.” That could be a covert comment on the current Kubernetes vs. Docker Swarm competition.
Monroy goes on to issue something of a minor mea culpa, noting that the union with Microsoft continues Deis’s mission “to make container technology easier to use.”
And there’s the rub. It’s not always easy to use. We’ve got a zillion cloud services and providers giving us an overabundance of tools, languages, technologies, platforms, and techniques. For all the problems legacy monolithic architecture presented, programmers (we didn’t call them developers back then) and SysOps staffers had few components to manage.
Today, here we are with lots and lots of pieces that need to be assembled, like a mosaic, into something that runs flawlessly, performs perfectly, provides unfettered access, supports instant change, and provides a business advantage. What do you do with all these little shards? You put them into containers and orchestrate their deployment and management so they, like a symphony orchestra, play together and become a whole that together is greater than the individual parts. After all, there’s a reason Kubernetes describes itself as “production-grade container orchestration.”
Where do you fall into line when it comes to containers and orchestration? For all the talk, it seems lots of IT operations have yet to dip their collective toes into the containerization waters? How about you? Actively using container technology in production? Working with an early proof-of-concept mini-project? Learning but haven’t taken the plunge yet? Share your experiences — and concerns — with us; we’d like to hear from you.
With Apple’s early June Worldwide Developers Conference a little more than two months away, it’s time to get moving, if you haven’t already, on one of the big changes almost certainly coming to iOS 11 — the dropping of support for apps that are not written for 64-bit processors.
According to a report from metrics provider SensorTower, the number of ripe-for-banishment 32-bit apps in the Apple app store hovered around 170,000 as of mid-March 2017. A big number, indeed, but it represents only about 8% of the approximately 2.4 million apps currently available in the app store. The good news is that the other 92% of listed apps are already 64-bit compatible.
Perhaps not surprisingly, the category with the most non-conforming apps is games at nearly 39,000. That’s about 20.6% of all the problem apps and nearly double the number of apps in the next offending category, education, just shy of 20,000. Other categories with a significant number of non-64-bit apps include entertainment, lifestyle, business, books, utilities, travel, and music. Only two categories have fewer than 1,000 offending apps, weather and shopping.
The high number of problem game apps is, of course, a reflection of the number of gaming apps in the app store in the first place. Gaming apps, many of them positively awful and almost always free, are often the domain of teenagers learning how to write code and do design. It makes sense then that these apps are the ones most likely to be abandoned as their creators mature, their coding skills evolve, and they move on to weightier projects. No doubt some of those apps were likely written to run on the now-defunct Parse platform — a popular choice for game development — but which were never migrated to another hosting environment and left to wither on the vine.
While this purge is all about 64-bitness, it’s not the first time Apple has made an attempt to clean house. In the first nine months of 2016, Apple deleted roughly 14,000 apps per month, according to SensorTower. That changed drastically in September 2016 when Apple started to notify developers that it would remove apps it considered outdated or which did not adhere to current various guidelines. You got 30 days to fix your app or it would be removed. The company wasn’t kidding — In October 2016, the number of apps purged soared to more than 47,000
The message is clear: If your app hasn’t been updated in eons, doesn’t comply with current standards, or is still mired in the 32-bit world, it’s headed for oblivion. Need some help to convert your app to a 64-bit binary? Fear not, Apple has an online guide that includes sample code. Better get busy.
Are your iOS apps up to date as 64-bit binaries? What difficulties to you encounter and how did you solve them? Do you have apps in the Apple app store that you simply choose to abandon? What tools do you use to build apps for iOS? Share your thoughts with us; we’d like to hear from you.
Cloud computing is a long way from being fully mature, but its obsolescence may already be upon us. Is the cloud’s future really up in the air?
As Peter Levine, a partner at venture capital firm Andreessen Horowitz, puts it, “Everything that’s popular in technology always gets replaced by something else,” be it Microsoft Windows, minicomputers exemplified by Digital Equipment Corp., specialized workstations typified by Sun Microsystems, or, yes, even cloud computing.
As Levine explains it, cloud computing, which he views as the centralization of IT workloads into a small number of super-mega-huge datacenters, is an unsustainable, unworkable, slow-to-respond method. The need for instantaneous information makes the network latency associated with a device-to-datacenter model and the corresponding datacenter-to-device return trip simply too long and therefore unacceptable.
Computing, Levine suggests, will move to a peer mesh of edge devices, migrating away from the centralized cloud model. Consider smart cars. They need to continually exchange information with each other about immediate, hyperlocal traffic conditions. Smart cars need to know that an accident occurred 10 seconds ago a half-mile up the road, that a pedestrian is entering a crosswalk, or that a traffic light is about to turn red. For this to work requires realtime data collection, processing, and sharing with other vehicles in the immediate area. The round-trip processing in the cloud model isn’t even remotely (pun intended) fast enough.
Text messaging is similar in that messages exchanged between people sitting just feet apart are still routed through a distant datacenter. It’s inefficient, slow (in compute terms), and unsustainable. The centralization is needed only for logging and journaling.
The answer, Levine postulates, is pushing processing and intelligence out to the edge, using many-to-many relationships among vehicles for information exchange, along with edge-based processing based on super-powerful machine-learning algorithms. No wonder he describes the self-driving car as “a datacenter on wheels.” Similarly, a drone is a datacenter with wings and a robot is a datacenter with arms and legs. They all need to process data in real time. The latency of the network plus the amount of information needing to travel renders the round-trip on the cloud unsuitable, though that’s still plenty fast enough for a Google search, he says.
The cloud still plays a role; data eventually needs to be stored, after all. That makes this model not fully edge and not fully cloud. It’s perhaps closer to what Cisco dubs “fog computing.” It also speaks to the inevitability of how IoT-driven smart cities must operate, a concept explained to me by Esmeralda Swartz, vice president of strategy and marketing at Ericsson.
There’s a profound irony to this. We started the age of IT (MIS as it was then known) with the IBM mainframe as the centralized place where all programs ran, all processing was done, and all data was stored. That was blown apart by decentralization, driven by the client/server model, Ethernet (or Token Ring or ARCnet), network operating systems (NetWare, VINES, LAN Manager, 3+ Open, Windows for Workgroups, Windows NT, OS/2 Warp, etc.) and early network-aware databases, such as Btrieve. Cloud computing swings the pendulum back to the centralized data model of the past, albeit with a dose of edge processing.
It’s throwing out everything you know and seeing from a paradoxically different perspective — just like the young girl presented on Christmas morning with her great-grandmother’s heirloom wristwatch, only to declare, “A watch that doesn’t need batteries? Gee, what will they think of next!”
You can watch Levine’s presentation “Return to the Edge and the End of Cloud Computing” on YouTube.
No doubt you’ve already thought about this. Where do you think cloud computing is headed? Is this a technology that is ultimately doomed to be superseded by something different, better, faster, and cheaper? What does this mean for you as an application developer? Share your thoughts and fears; we’d like to hear from you.
Now that La La Land Moonlight has won the Academy Award for best picture, this is as good a time as any to look back at some screw-ups in the world of cloud computing. May we all learn from our mistakes.
The Force is not with you: Take a trip back to May 9, 2016, less than a year ago. It was on that day the Silicon Valley NA14 instance of Salesforce.com went offline, a condition colloquially known as Total Inability To Support Usual Performance (I’m not going anywhere near the acronym). Customers lost several hours of data and the outage dragged on for nearly 24 hours. CEO Mark Benioff took to his Twitter account to ask for forgiveness. Shortly after, Salesforce moved some of its workloads to Amazon Web Services.
AWS giveth, AWS taketh away: Though transferring workloads to AWS helped Salesforce recover lost customer confidence (though not lost data), the opposite was true for Netflix. On Christmas Eve 2012, at a time when kids might be watching back-to-back-to-back showings of A Christmas Story, problems with AWS’s Elastic Load Balancing service caused Netflix to go down. This Grinch stole Christmas not just from little Cindy Loo Who, but from millions of paying subscribers waiting to see if Ralphie gets his dreamed-about Red Ryder BB rifle. Lessons were learned. Two years later, during a massive AWS EC2 update, Netflix rebooted 218 of its 2,700 production nodes. Alarmingly, 22 failed to reboot, but, the Netflix service never went offline. At the opposing end, Dropbox went old school in March 2016, dumping AWS and moving its entire operation onto its own newly built, enormous infrastructure.
Those darn updates’ll getcha every time: Amid verdant woodlands, beneath pure azure skies, protected by mountains, our cloud service lies. That bucolic portrait of the Pacific Northwest (or New Hampshire, perhaps) mattered little to Microsoft on Nov. 18, 2014 when the Azure Storage Service suffered a widespread outage traced back to the tiered rollout of software updates intended to improve performance. “We discovered an issue that resulted in storage blob front ends going into an infinite loop, which had gone undetected…” was the blogged explanation. Another major outage occurred in Dec. 2015.
Eat in, Dyn out: The Oct. 21, 2016 wave of coordinated distributed denial-of-service attacks targeting Domain Name System provider Dyn impacted dozens of high-profile businesses to varying degrees. These included Airbnb, Twitter, Amazon, Ancestry, Netflix, PayPal, and a long list of others. Dyn’s own detailed post-mortem of the attack makes for fascinating reading. If you think it’s impossible for millions of geographically far-flung, seemingly unrelated IoT devices to attack in a coordinated manner, think again.
You’ve heard of Office 360? Sure you have. The name is favored among cynics who joke that Microsoft’s cloud-based productivity software should be called that because it is offline five days out of every year. Office 365’s e-mail service was down for many users for about 12 hours on June 30, 2016. That follows other outages in various geographies on Dec. 3, 2015; Dec. 18, 2015; Jan. 18, 2016; and Feb. 22, 2016.
Got healthcare? We all know the stories about how healthcare.gov kept crashing due to poor design, inadequate compute resources, demand that vastly exceeded expectations, and so on. Enough said.
What’s that one cloud disaster story you’ve been dying to share? Now’s your chance. Tell us all about it; we’d like to hear from you.
One of the things I look forward to each year at this time is the release of the annual State of the Cloud report from cloud services provider RightScale. That may say more about the quality of my social life than anything else; nevertheless, the study always contains great insight into the psyche of cloud computing technology professionals. Let’s dive into some key findings. The survey is being published today (2/15/2017) and is based on research undertaken in January 2017. A compendium of fresher opinions you’ll not find.
Hybrid up, private down: A multi-cloud strategy exists in 85% of surveyed enterprises, up from 82% in Jan. 2016. But, look at the other side: Private cloud adoption fell to 72% from 77%. What that means is momentum is swinging to the public cloud.
The cloud is just as wasteful as traditional IT: Here’s a real shocker: Survey respondents estimate that 30% of cloud spending is wasted. RightScale’s own research pegs waste even higher, between 30% and 45%. How in the world — or in the cloud — did this happen, and happen so quickly? According to RightScale, despite growing scrutiny on cloud cost management, few companies are actively spinning down unused resources or selecting lower-cost clouds or regions.
Survey respondents estimate that 30% of cloud spending is wasted. How in the world — or in the cloud — did this happen, and happen so quickly?
IT is taking control: So-called citizen IT and shadow IT aren’t going away, nor are no-code / low-code technologies that empower line-of-business departments to build solutions. Despite this, it is IT that selects public cloud providers (cited by 65% of respondents) and it is IT that decides which apps to migrate into the cloud (63%).
The majority of enterprise workloads are now in the cloud. The study revealed that 41% of workloads run in public clouds and 38% in private clouds. Among larger enterprises the numbers differ slightly, with 32% of workloads in public cloud and 43% in private clouds.
It’s a multi-cloud world, after all: According to the study, public cloud users are already running apps in 1.8 public clouds while private cloud users are leveraging 2.3 private clouds. Those numbers strike me as being surprisingly low.
It’s a DevOps world, too: Whether you believe in DevOps or not, it’s here to stay, now embraced by 84% of large enterprises. The expansion of DevOps into BizDevOps that brings the business side into the mix is also on the rise, now used in 30% of enterprises, compared with 21% just a year ago.
It’s getting better every day: Even though the talent shortage remains the top challenge facing IT, it’s less of a concern than a year ago, falling to 25% from 32%. Security concerns also abated slightly, dropping to 25% from 29%. Mature cloud cite managing costs as a key concern while newbies worry more about security.
Docker is moving like a tremendous machine: Docker adoption is surging, leaving Chef and Puppet in the dust. Kubernetes use doubled. Interestingly, 35% of survey respondents indicated they’ve gone with the container-as-a-service approach from AWS ECS (35%), Azure Container Service (11%), and Google Container Engine (8%).
Azure cuts into AWS’s lead: Azure adoption soared to 34% from 20% a year ago as AWS stayed flat, but in the lead at 57%.
This annual study isn’t the only one out there, but it does provide a good snapshot of how the cloud changes from year to year. Now it’s time for you to respond. Where are you seeing wasteful cloud spending? Is your organization thoroughly immersed in DevOps and BizDevOps? Are your app development efforts all containers all the time? Finally, what cloud platforms are you using, to what extent, and how has that changed over time. Share your experiences with your counterparts; we’d like to hear from you.
In a story that circulated worldwide last week, it was reported that a hotel in Austria, the Seehotel Jaegerwirt, had been attacked by hackers who disabled the guestroom cardkey system, locking guests in their rooms until the hotel paid a Bitcoin ransom. That’s not exactly accurate, but enough of it is true to merit some serious discussion.
According to published reports correcting the initial misinformation, hackers did take control of the cardkey system, but only to the extent that the encoding of new key cards was disabled for guests in the process of checking in. Doors were never immobilized and guests were never trapped. Nevertheless, a ransom was indeed paid in Bitcoin currency by the hotel to have its systems and data released. And it’s apparently not the first time. The bottom line is that the hotel reportedly is planning a return to good, old-fashioned metal keys.
Think devious, think scheming, think cunning, because the people writing malware are doing exactly that, and they’re doing it better than you.
This situation probably has little to do with any of the three big makers of hospitality cardkey systems, Onity, OpenKey, and Salto Systems. It’s likely more about the bad guys being invited in on a red carpet right through a hotel’s front door. We’ve all heard the stories before — clicking on an innocent-looking link in an email message, inserting into a USB port a flash drive that contains malware, network hardware configured with default passwords, unprotected ports, and so on. One thing is for sure: We’re not far from IoT becoming an acronym for the “Internet of Thugs.”
Of course, there’s a cloud and mobile application development angle to this. We’re well beyond magstripe key cards or ones with embedded RFID tags. Indeed, the newest advancement in room-access technology is the complete elimination of the card. An app on your smartphone that uses proximity Bluetooth to communicate with the door lock is very much a reality and being installed in hotels worldwide. It’s yet another inevitable use of cloud and mobile computing technology.
While the vulnerability in this particular case may lie more in the area of network infrastructure management, it’s no less important for anyone cranking out lines of code to always keep security top of mind. It’s useful to approach any coding project with profound skepticism about its security and potential vulnerabilities. Think devious, think scheming, think cunning, because the people writing malware are doing exactly that, and they’re doing it better than you.
Consider this: According to a Dec. 2016 blog post by Amol Sarwate, director of vulnerability labs at security firm Qualys, Microsoft issued 155 security bulletins for the year, up 15% from 2015. Over the lifetime of Windows 7, it added up to many hundreds of security patches being issued. If a smart company like Microsoft (or Apple, or Adobe, or Android, or Oracle, any other company) can’t build software that’s secure, how in the world can you?
What glaring vulnerabilities were overlooked in the design of software that you coded? How were these vulnerabilities corrected and users notified? Share your horror stories; we’d like to hear from you.
Whether you read my site, SearchCloudApplications, another of the TechTarget family of websites, or any of the seemingly trillions of sites that write about application-development technology, three items stand atop the heap of coverage: containers, microservices, and APIs.
For the moment, let’s talks about APIs.
In a story I wrote this week about Shufflrr, a New York provider of SaaS-based presentation-management services, founder and CEO James Ontra revealed what’s under the hood. I always ask when interviewing a software company, because this is the sort of thing that other developers want to know.
Shufflrr’s business model is to provide businesses with a way to catalog and control their vast collection of PowerPoint and other presentations. Employees can view all and create new presentations through drag-and-drop of individual slides in the archive. Viewed online by potential customers, highly detailed tracking of which slides were viewed, for how long, along with other metrics are available. For enterprises with large salesforces, it’s a great idea.
“Every feature, function, and use is transmitted through APIs, which gives us the ability to grow our platform.”
Turns out this SaaS offering is hosted on Amazon Web Services. No surprise there. But, more interesting, the front end was built with Bootstrap, a platform developed at Twitter and which I don’t recall anyone ever speaking about before. Bootstrap is an open-source front-end framework based on HTML and CSS design templates for building web-based and mobile applications that work on and format properly for any device. Beyond that, the Shufflrr ecosystem employs the Microsoft stack on .NET using SQL.
Here’s the gem: Ontra explains the entire Shufflrr site is run by APIs and goes on to say, “Every feature, function, and use is transmitted through APIs, which gives us the ability to grow our platform.”
And there you have it in 18 words. Through the pervasive use of APIs, development is simplified. Internal process workflows and connections to external data sources are handled in a consistent manner no matter who the code jockey is. Customers can write their own extensions, if desired. Cheaper. Faster. Better. Consistent. Secure.
This, of course, is much easier when you are, like Shufflrr, a young company with zero legacy data and no legacy applications. The clean-sheet approach does have it advantages.
How pervasive is your company’s use of API technology? Share your thought on the good, the bad, and the ugly of designing, implementing, and managing APIs, either your own or those provided by third parties. We’d like to hear from you.
People change jobs. It’s a fact of life. And it’s dangerous.
While departing employees routinely stuff their pockets with Sharpies and paper clips to stock their home offices, it’s those piles of ones and zeroes walking out the door with them that should have us all terrified.
Consider this one finding cited in a brand new January 2017 white paper from Osterman Research: Fully 87% of departing employees take data they created and 28% take data created by others.
What are they taking, you ask? Nearly 90 took presentations or strategy documents, 31% took customer lists, and 25% took intellectual property. That last category is where program code fits. (And we’re not even talking about hackers.)
Some of this is intentional, some isn’t. The white paper notes that departmental so-called citizen developers are likely to have content on their personal devices. Part- or full-time telecommuters who use their home computers for work often have content stored locally. And yes, of course there are those who abscond with content on purpose. Limiting access does no good as these are the people who are supposed to have access.
But, some is intentional. The white paper discusses one software developer who learned she was to be terminated and began downloading “trade secrets,” which I interpret as code. The company initiated emergency legal action to prevent competitors from accessing the data. It happened at Goldman Sachs and even at security vendor Symantec.
Bob Spurzem, the go-to-market guru at Archive360 notes that it is common for developers that leave a company to take code with them. Beyond merely protecting a business’s data and other intellectual property when employees leave, “software developers require special attention,” he says.
“While we would like to believe this would never happen, a disgruntled developer leaving a business organization could steal code that equates to months, even years of work — putting a company’s competitive edge at serious risk,” Spurzem says. “These threats are very real. Dismissing them to the back burner is a dangerous mistake. Businesses must plan for and take the appropriate steps to mitigate the risk.”
As I see it, it’s not just access to code. It’s also about access to design specs, test scripts, and subscription-based public cloud platform-as-a-service development environments. It’s about spinning up servers and database instances. Who’s in charge of disabling the departed one’s accounts? Or is he or she still using these development tools? Who is administering the administrators?
Have you known colleagues to take application code? (Of course, you would never do this.) What did your company do about it? And what measures does your organization have in place to prevent theft of code? Share your thoughts, we’d like to hear from you.
The cloud, to varying degrees, did away with the need to manage huge, on-premises IT infrastructures. Fortunately, IT staffers on company payrolls were still needed to migrate apps and data, and manage these new-fangled, cloud-based, virtual infrastructures. Now, with 2017 just days away, it’s fair to ask if that management role is on the cusp of disappearing, too,
Not surprisingly, it’s Amazon shaking things up again. On Dec. 12, 2016, Amazon launched AWS Managed Services (AWSMS), essentially Amazon’s offer to provide fee-based infrastructure operations management for your enterprise.
In his blog post announcing the service, AWS chief evangelist Jeff Barr said organizations want to “relieve their staff of as many routine operational duties as possible.” You’ve got to wonder if the CFO interprets that as “relieving as many staff as possible.”
Targeting the Fortune 1000 and Global 2000 enterprises (yes, it’ll trickle down eventually), AWSMS, according to Barr is “backed up by a dedicated team of Amazon employees” ready to provide incident monitoring and resolution, change control, provisioning, patch management, security and access management, backup and restore, along with reporting. An IT department can connect AWSMS to its own management tools (if you still opt to have any) via a new API and command-line interface.
So, Amazon can host your entire IT operation and now manage every aspect of it. It can warehouse and fulfill customer orders for the products you sell. With its own in-the-making fleet of trucks, drones, and aircraft, it can package and ship to your customer’s door. It can provide credit-card processing.
With drone delivery now a reality after a successful tryout in the U.K., there’s isn’t much that Amazon can’t do, except, perhaps, for the actual act of coding new applications. And, of course, there are tools to vastly simplify that process, too.
After all of this, the only ones left standing could be application developers, despite — or thanks to — Amazon’s vast array of development tools. No matter how much of a business’s IT operation Amazon hosts, operates, or manages, Amazon can’t know what it is you want your application to do. For that reason, I can’t imagine AWS wanting to build applications for you.
The managed services aspect was previously the domain of specialized IT staffers or other third-party managed service providers (MSPs), typified by Rackspace, but Amazon — at least for now — has them covered. Instead of cutting MSPs out of the ecosystem, AWSMS is positioned to embrace them. Partners have the opportunity to provide four different services specific to AWSMS, including onboarding, integration with customer ITSMs, application migration, and application operations.
Where do you come down on this? Is your organization ready to cede ops management to AWSMS? How does this change your IT plans for 2017 and beyond? No doubt have pretty strong opinions about this. It’s the season for sharing, so share those opinions with us. We’d like to hear from you.
Here’s a line I’ve been writing for many years: Hardware is nothing more than software that breaks if you drop it. It’s true because everything from a toaster oven to thermostat to, well, just about anything else is loaded with embedded software. Even today’s vehicles are essentially little more than highly complex mobile computers with seating for five and cargo space.
While we’re busy gushing about the latest mobile and cloud applications, it is the software embedded in dishwashers, IoT sensors, microwave ovens, digital cameras, vehicles, and even self-synchronizing wall clocks that may be real stars. There’s a lot more to software than user-facing applications, after all.
According to data published in June 2016 by Global Market Insights, the embedded software market size, valued at $10.46 billion in 2015, is predicted to register a 7% compound annual growth rate (CAGR) through 2023, rising to about $18 billion.
One key driver is automotive. According to Global Market Insights, the automotive embedded systems market accounted for roughly 22% share in 2014, with CAGR gains estimated at 5.5% from 2016 to 2023. Smart vehicles, navigation capability, and car-to-road communication, along with the rise of hybrid and electric vehicles are behind the growing numbers.
Another obvious growth market is wearable devices. “Growing use of wearable embedded equipment across many applications like medical, security, fitness and safety is predicted to promote embedded software industry trends,” the report notes. Increasing customer demand for electronic equipment like computers, tablets and smartphones is predicted to enhance the demand for the industry further.
The report defines embedded software as consisting of tools, middleware, and operating systems. There’s a rise in the use of Java in mobile devices behind technologies that include near-field communications.
This is also about highly specialized real-time operating systems, such as VxWorks from Wind River, ThreadX from Express Logic, and the open-source Fusion Embedded RTOS from Unicoi Systems for starters.
If you’ve worked on embedded software of any kind, we’d like to hear from you. What is the nature of the software you’ve written and on what kinds of devices is it running? There’s lots to talk about and plenty of opportunity for software engineers looking to expand their horizons. Join the conversation.