devopsy.kinsta.cloud

Tag: managed services

  • Sparkhound Unveils Pop-Up Service Desk

    Sparkhound Unveils Pop-Up Service Desk

    Sparkhound, a provider of managed IT services, has launched a Pop-Up Service Desk designed to augment the existing capabilities of internal IT teams during a major transition.

    Chris Kimmel, managing director for managed services at Sparkhound, said the new service was created to help organizations cope with transitions such as migrating to Windows 10 or deploying a major upgrade to an electronic medical record system.

    In both cases, Kimmel said it’s not uncommon for internal IT service desk personnel to be overwhelmed by requests for support. In some instances, organizations have decided to rely on Sparkhound, a provider of IT services that are available 24/7, to handle all the calls specifically relating to Windows 10 until such time the volume of support calls declines to a point where they can be handled by the internal IT team. In other cases, he said, Sparkhound has acted as a concierge that triages support calls before passing them on to a professional services team that has been contracted to implement an EMR system.

    IT teams can also “white-label” the Pop-Up Service Desk service in a way that makes the Sparkhound team appear to be an extension of the company’s internal IT service desk.

    Tensions between internal IT teams and managed service providers (MSPs) such as Sparkhound are long-standing. Many internal IT teams fear they will be replaced by an MSP. However, while Sparkhound continues to offer a wide range of managed IT services, Kimmel said none of the customers who have trialed Pop-Up Service Desk have opted to replace their internal IT staff.

    While most MSPs have an advantage in terms of technical expertise because of their ability to invest more in IT automation frameworks, many organizations still prefer to hire full-time employees to manage IT because they typically develop a closer relationship with end users. Less clear is to what degree managed services are less expensive to employ as an operational expense versus the fully loaded cost of hiring an internal IT team. The Pop-Up Service Desk allows organizations to strike a middle ground between those two extremes at times of stress.

    Kimmel said the services provided by Sparkhound are based on the ITIL framework. More organizations served by Sparkhound have yet to adopt best DevOps practices for building and deploying applications. However, Kimmel said the MSP will be prepared to make that transition if and when it comes.

    In the meantime, a chronic shortage of all types of IT skills is pushing more organizations to at the very least consider managed IT services as an alternative to hiring an internal IT team. The global managed services market is forecasted to be valued at $376 billion by 2025, representing an 11.7% compound annual growth rate.

    IT professionals who would prefer to see the management of IT remain in-house are under constant pressure to show more value. Alternatively, many IT professionals can simply opt to go to work for an MSP.

    Regardless of the route chosen, however, it’s apparent most internal IT teams can’t keep pace with the rate of change now occurring across the IT landscape. Whether it’s maintaining security or simply upgrading applications, few internal IT teams are going to have all the skills required to succeed, so like it or not, managed services are now a permanent part of the IT ecosystem.

    — Mike Vizard

  • HPE Adds Control Plane to Greenlake Managed Service

    HPE Adds Control Plane to Greenlake Managed Service

    Hewlett-Packard Enterprise (HPE) announced today it has added a cloud platform to its managed Greenlake service, through which DevOps teams will be able to manage deployments of applications alongside HPE.

    Scott Yow, vice president and general manager for GreenLake Hybrid Cloud Software at HPE, said HPE Greenlake Central provides a control plane that makes it possible for DevOps teams to write, release and deploy code quickly, without having to manage the IT infrastructure directly in an on-premises IT environment.

    Instead, DevOps teams will have access to an array of tools and services from HPE and partners through a marketplace to create a workbench through which they can design and create applications using best DevOps practices, said Yow. For example, HPE will make it possible for DevOps teams to leverage Terraform tools from HashiCorp to enable DevOps teams to manage infrastructure as code.

    Announced at the HPE Discover More Munich event, GreenLake Central is in trial with general availability scheduled for the end of the first quarter of 2020. The goal is to make it possible for DevOps teams to access distributed IT infrastructure in an on-premises IT environment that is managed in much the same way cloud platforms are accessed, said Yow. HPE will provide the expertise required to consistently manage underlying IT infrastructure, while DevOps teams employ Greenlake Central to manage the application environment.

    The Greenlake service also surfaces a dashboard through which IT teams can leverage more than 1,000 controls to meet almost any compliance mandates. Reports generated via that console substantially reduce the time and effort required to audit the IT environment as well.

    HPE is essentially making available a “co-pilot” approach to managing IT infrastructure that enables DevOps teams to focus more of their efforts on managing applications. HPE also published the results of a survey of 1,000 IT decision-makers that finds 86% of respondents agree that “as-a-service” approaches to managing IT are now inevitable and 75% expect their organization to move toward full adoption of such models in less than five years.

    Today the Greenlake service is designed around a series of virtual machine options spanning offerings from HPE, Nutanix and VMware. However, HPE plans to add support next year for a recently launched HPE Container Platform that can be deployed on top of virtual machines or bare-metal servers. IT organizations also should expect HPE to extend the Greenlake control plane to public clouds to advance hybrid cloud computing to ensure IT organizations maintain ownership of the control plane to manage those environments, Yow said.

    Greenlake is at the forefront of an HPE initiative to transition all its offerings into a set of managed services. That “as-a-service” approach has already gained traction with more than 740 customers worldwide, including 160 new customer wins this year. By 2022, HPE has promised to make its entire portfolio available as a service.

    HPE is not the only provider of IT infrastructure leveraging managed services to provide DevOps teams with access to a more flexible IT environment. Historically, these types of managed services were provided by third-party IT services providers. In the age of the cloud, HPE is betting more organizations will prefer to have their IT infrastructure managed by the vendor that built it in the first place. Of course, as part of that transition, HPE is making a case for standardizing on its infrastructure.

    It’s too early to say how the marriage of DevOps and managed services will play out in on-premises IT environments. The one thing that is clear, however, is that DevOps teams increasingly need to manage the IT infrastructure on which their applications are deployed only if they really feel the need to do so.

    — Mike Vizard

  • CloudBees Allies with Atos to Accelerate DevOps Adoption

    CloudBees Allies with Atos to Accelerate DevOps Adoption

    In a move that should accelerate adoption of best DevOps practices in the enterprise, CloudBees and Atos announced this week that the two are collaborating to advance adoption of continuous integration/continuous development (CI/CD) platforms on the Google public cloud.

    Announced at the Google Cloud Next 2019 conference, the alliance will result in the IT services giant delivering a managed instance of a CloudBees CI/CD platform running on the Google cloud, in addition to providing traditional consulting services.

    Francois Dechery, chief strategy officer for CloudBees, said the alliance with Atos will accelerate adoption of DevOps processes in traditional enterprise IT organizations as Atos consultants engage customers looking to modernize their application development and deployment processes. In fact, many of the principles first pioneered by proponents of agile development methodologies are now being applied to business process management, he noted.

    Atos plans to add a DevOps practice as a complement to its existing processes. Michael Kollar, senior vice president for cloud engineering, said the company expects that, for the foreseeable future, most of their clients will be trying to meld some degree of DevOps and existing ITIL-based approaches to IT services management (ITSM). The alliance with Google will go a long way to accelerating that transition because it will allow Atos to deliver access to a CI/CD platform based on a consumption model that reflects the way public cloud infrastructure is consumed, he said.

    Kollar noted enterprise IT organizations are under more pressure than ever to deliver applications faster as more organizations recognize they are a software company that happens to make something. Most organizations today need to create a superior customer experience through software to differentiate themselves from their competition, he said.

    Many of those companies will need help setting up the processes that will enable them to function as a software company, he added. The biggest challenge, however, is finding a way to meld new ways of building and deploying applications with investments in legacy systems on which the business still depends, he said.

    Naturally, Atos won’t be the only IT services firm to launch a managed DevOps process. But as more IT services firms invest in developing managed services, there will be need for a balance between the managed services provided by IT services providers and cloud service providers such as Google and the IT services that will continue to be managed and delivered by internal IT organizations. The degree to which organizations will rely on external IT services firms for DevOps will be dictated by how mature they are today. But it does not follow that an organization which sees a need to rely on external expertise today will be that position tomorrow. As more organizations develop internal expertise, a managed service provider will need to earn its seat at the table every time its contract comes up for renewal.

    — Mike Vizard

  • The Truth Behind DevOps on the Cloud

    The Truth Behind DevOps on the Cloud

    DevOps on the cloud may seem simple enough, but in reality it can be very complex

    The ultimate goal of a DevOps administrator is to make sure that everything is running properly and seamlessly—so much so that management is convinced that the DevOps administrator is playing solitaire all day. To that end, a successful DevOps team should have their systems automated such that the level of friction they impose on the organization is minimal.

    Leveraging a cloud environment makes it look easy—almost too easy, making it look as though all DevOps needs to do is press a button. IT can be deceived into thinking that the level of complexity in DevOps on the cloud is trivial, when in reality it is not.

    Running DevOps on the cloud is like renting an apartment in someone else’s building: Even though you don’t own the infrastructure, you’ll have to deal with any issues that may arise. Similarly to a neighbor who’s too noisy, you may experience different levels of performance from the same servers with the same capacity at different times of the day because someone else is running on the same hardware.

    There also are security threats that don’t come into play when running on your own hardware. If the same physical machine that runs your most important computations is also being used by Mr. Nefarious, he can use all sorts of tricks and hacks to gain access to valuable data. The Meltdown Inspector attacks is one example—it impacted all cloud providers with severe fleetwide performance impact, sometimes exceeding 10 percent, and required expensive mitigation steps.

    Making Sense of Your Gold Mine of Data

    The wealth of information provided to system administrators is awe-inspiring, terrifying and frustrating all at once. There is so much information available that, in theory, we should be able to troubleshoot and fix any and all issues. Unfortunately, making sense of the vast amount of information available and nailing down the critical pieces of information necessary can be extremely complex.

    The flat network topology typically expected of an on-premises data center is drastically more complex on the cloud. Beyond just VPN and DMZ, there are multiple isolated networks, containers running VMs and running on segmented networks going through NAT with multiple levels of routing and dispatch at play. Trying to troubleshoot in such an environment can be an exercise in frustration, because you don’t own the entire network.

    Certain tools and abilities you might take for granted in your own data center are not available, such as Tcpdump, a low-level tool to monitor network packets. For example, in VPN packet loss scenario, your cloud VPN server is shared with other clients, so  you won’t be able to capture packets to troubleshoot the connection issues.

    Also in managed services—in particular databases—the debug endpoints and tools that often are used in other environments to troubleshoot are not available, to avoid exposing data from other users. For example, you cannot get the full logs from the server to figure out what it is doing. That can hide critical goings that are too precious to ignore in production.

    Evaluating Cloud Providers

    Since it’s inevitable that problems will occur, one of the important considerations for selecting a cloud provider is the level and quality of support they offer. It’s important to go beyond simple SLAs and evaluate the actual quality and effectiveness of the support you can receive.

    Take, for instance, a situation where a machine would freeze, effectively at random, for long periods of time. All monitoring and metrics have told a simple story. The machine was up, had plenty of resources and capacity to spare, but simply would not respond every now and then for any connection attempt whatsoever. Troubleshooting involved stripping the problem to its core and being able to reproduce this in a minimal fashion, at which point one would contact the cloud provider support to try and understand what is going on. The actual problem turned out to be network port exhaustion in the NAT router, which caused a remote server to reset TCP connections, leading to long timeouts that froze the system. This particular problem took days to resolve and required a major change in the deployment topology.

    Running DevOps on the cloud is not an easy task, and the cloud itself is not a silver bullet. Rather, it’s a way to democratize hardware and operation resources and work effectively at scale. If you can manage the new challenges, you can enjoy a new level of efficiency.

    — Oren Eini

  • IBM: DevOps Challenges Require Managed Services

    IBM: DevOps Challenges Require Managed Services

    The DevOps complexity associated with determining which classes of application workloads are best-suited to run on certain platform types will push an increasing number of IT organizations to embrace managed services. That’s the premise put forth by IBM, which provides such a service.

    Steve Robinson, general manager for IBM Cloud Platform Services, says it’s becoming less likely that internal IT operations teams will have the tools and expertise required to analyze and optimally deploy workloads. In fact, the number of platform choices have already exceeded the ability of most internal IT organizations to master. They include:

    • Traditional virtual machines: The most widely deployed form a virtual machine software comes from VMware. But there’s already a lot of interest starting to emerge in so-called “micro VMs” that promise to reduce the memory footprint of VMs. However, rather than replacing traditional VMs, it’s probable micro VMs would be deployed alongside traditional VMs.
    • Containers: Most containers today are deployed on top of virtual machines because of a lack of tools as well as security concerns. But as IT organizations become more adept at managing containers, many more of those containers will wind up running on bare-metal servers that will be able to attain much higher utilization rates by eliminating the need to deploy traditional virtual machines.
    • Serverless Computing: Based on event-driven architecture, these platforms can be invoked natively as functions or simply be used to host containers. In either case, the need to provision servers, storage and networking resources is eliminated because IT infrastructure resources are made available on demand in real time.
    • Graphical Processing Units (GPUs): As an alternative to Intel Xeon class processors, GPUs now are taking on many workloads involving machine-learning algorithms and big data because of their ability to process many of those workloads in parallel.
    • Field Programmable Gate Arrays (FPGAs): Based on custom integrated circuits, FPGAs are being more widely employed within a variety of cloud services.

    IT organizations today have the option to deploy any of these technologies on-premises or invoke them in the cloud. The issue most are contending with is a lack of advanced IT skills. In the absence of those skills, many IT organizations are in peril of falling behind their rivals. To overcome that issue, Robinson says it’s easier for many organizations to rely on third-party providers to manage their infrastructure while they concentrate their limited resources on application development.

    Any increased reliance on managed services to gain the benefits of a more sophisticated approach to DevOps will vary widely by organization. Crafting DevOps process that span third-party organizations takes time and effort. There’s no way to analyze a workload and then automatically deploy it on the optimal platform without any human intervention. But as IT organizations continue to struggle with mastering DevOps processes, many may conclude it makes the most sense to rely on the expertise of a third-party service provider to manage a hybrid approach to DevOps. Regardless, the pressure to show results by increasing the amount of high-quality code being generated across the enterprise is mounting.

    — Mike Vizard

  • Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    Pivotal Enlists Rackspace to Advance DevOps in Cloud Foundry Environments

    In a sign of the level of complexity now associated with managing DevOps, Pivotal has partnered with Rackspace to create a managed services practice for its distribution of the Cloud Foundry platform-as-a-service (PaaS) environment.

    Ian Andrews, vice president of product for Pivotal, says that at least half of the company’s customers have a least one instance of Pivotal Cloud Foundry (CF) that they would like to have managed by a third party. The reason for that is two-fold. For one, the Cloud Foundry PaaS can be complex for many IT organizations to deploy and manage on their own; Andrews notes that Pivotal releases updates to its distribution of the Cloud Foundry PaaS every 90 days. That’s a cadence the average internal IT organization is not prepared to keep pace with without help from an external services provider, he says.

    Also, increased usage of microservices based on containers running on Cloud Foundry is driving organizations to shift allocation of their own internal resources away from managing underlying infrastructure. By relying on managed services providers such as Rackspace to manage both the PaaS and the underlying infrastructure, Andrews says more resources can be focused on managing the DevOps pipeline.

    Pivotal opted to partner with Rackspace because Rackspace is capable to supporting instances of Cloud Foundry running on a public cloud, in a hosting center or on-premises, he says, adding that 60 percent of the Pivotal instances run on VMware vSphere platform, while the rest are distributed across multiple clouds and other on-premises environments. Pivotal is a sister company of VMware, operating under the umbrella of Dell Technologies.

    Brannon Lacey, vice president and general manager for applications and platforms at Rackspace, says his company is embracing Pivotal as part of a larger push to deliver managed services above the infrastructure level. Previously, Lacey says, Rackspace managed e-commerce and content management applications, then acquired TriCore to add a portfolio of managed ERP application services. However, the company doesn’t have any plans to add more PaaS environments to its portfolio beyond the Cloud Foundry PaaS curated by Pivotal.

    Historically, managed services have accounted for about a quarter of all IT spending. But as the number of deployment options available to IT organizations continue to expand, Lacey says Rackspace is expecting the number of companies that look beyond their internal IT organizations to manage that complexity will only increase.

    As more managed services providers become part of the DevOps pipeline, it’s clear that many companies will soon need to consider how to create processes that extend well beyond their own organizations. That may prove to be a significant challenge because of the cadence of the update process is dictated by the external entities. Of course, IT organizations can dictate the pace of the upgrades. But the further an IT organization falls behind in terms of upgrades, the more expensive the managed service tends to become. In short, there’s no such thing as a proverbial DevOps easy button.

    — Mike Vizard

  • Tips to Optimize the Cloud for Scaling

    Tips to Optimize the Cloud for Scaling

    When I first started migrating companies to the cloud (about seven years ago), companies would ask me, “How come the app isn’t scaling? How come users are still complaining about the slowness?” I would explain that the cloud enables auto-scaling, but you still have to make sure your app can scale in the cloud. In people’s minds, auto-scaling and the cloud was synonyms.

    I don’t get asked that question anymore (maybe people realized the cloud is not as magical as it seems). But now, people think the cloud is synonymous with speed, agility and cost-effectiveness. Sure, cloud enables all that. But you still need to make sure you optimize the cloud to facilitate that. I see many companies in the opposite situation: their accounts full of resources with names such as test1, test2 and finaltest2, or they put together a SWAT team to reduce an AWS bill, or security is an afterthought. So many engineers are making changes, it’s hard to know who is doing what.

    Before you run into this situation (maybe you’re already there), you have to create tools and processes to optimize your cloud for scale.

    Establish Strong Policies

    The magnitude of changes in cloud infrastructure is high. Unless you establish strong policies, managing all the resources across multiple cloud accounts get out of control pretty quickly. The most effective way we have seen is using tags for resources. For example, use tags that identify whether the resource is from a certain department are added to each resource. Typically, it works very well when the tagging process is embedded into the automation. If there are new resources that don’t comply, automation should terminate these resources. You should enforce policies like these sooner than later.

    And just because these resources were provisioned with proper tagging, it doesn’t mean they are provisioned for its full capacity. You should build automation to find underutilized instances and establish a process for downsizing. To ensure everyone complies with these policies, you should also establish change management process.

    Change Management and CMDB

    The objective of the change management process is to ensure all the infrastructure changes cause minimum disruption and meet internal guidelines. Many say that ITIL change management process is not compatible for fast environments such as cloud. I agree that the traditional way of doing change management by tracking changes manually just doesn’t work, due to the magnitude of changes. But in the cloud, you can leverage automation to streamline the change management process; for example, you can use automation to filter normal changes versus manual changes. Once all the AWS changes are reviewed and approved, in addition to bringing visibility to all the changes for security and reliability change management can simultaneously help reduce waste.

    Most companies heavily leverage auto-scaling, where new resources can be launched based on specified metrics. However, this behavior makes approving changes difficult. If new resources are appearing and disappearing, how do we track what truly changed in the infrastructure? To gain a true picture, you need an infrastructure delta, which shows resource updates for the still-running resources for a given time period. You can also use automation to build a dynamic change management database, and use auto-discovery to keep CMDB in sync.

    Shared Responsibility

    DevOps calls for breaking down the walls between operation and development team to deliver code faster. If you release software fast, you can rapidly add value to your customer. The cloud enables this culture because developers no longer have to wait for IT to provision resources. What doesn’t work well, though, is when no one takes responsibility for optimizing cost and maintaining security. If engineers can launch resources, they are also responsible for cost and security—it’s a shared responsibility. You should provide visibility to the cost for each department, based on tagging we talked about earlier, so they know the cloud is not free 🙂 Anyone can launch resources as long as they understand the security best practices for each service they are using.

    Conclusion

    Lean thinking calls for reducing waste. What’s waste? Anything that doesn’t add value to the customer. You should work fearlessly to reduce waste. You move to the cloud because you can innovate fast and it’s cost-effective, so you can quickly add value to your customer. You should continue to optimize your cloud infrastructure to ensure it’s meeting its original intent.

    About the Author / JT Giri

    JT is the creator of nOps – AWS cloud security tool. He spent last 10 years helping companies migrate to cloud and build automated infrastructures. nOps is a next generation security and collaboration solution for the cloud. nOps applies change management practices to deliver integrated security and reduce cloud waste.

  • AWS Extends DevOps Ambitions via Managed Services

    AWS Extends DevOps Ambitions via Managed Services

    Amazon Web Services (AWS) is signaling its increased interest in providing managed services spanning multiple aspects of DevOps with the launch of service that promises to make it easier to set up development projects.

    At a recent AWS Summit conference in San Francisco, CTO Werner Vogels described AWS CodeStar as a means for building pipelines using templates that span more than 90 different AWS services. The templates currently support five different programming environments: JavaScript, Java, Python, Ruby and PHP.

    CodeStar automates configuration of a continuous delivery pipeline for each project using CodeCommit, CodeBuild, CodePipeline and CodeDeploy, as well as providing integration with Atlassian JIRA Software for tracking issues via the CodeStar console. There also is a preconfigured project management dashboard for tracking activities such as code commits, build results and deployment activity.

    Over the past couple of years, AWS has expanded the number of managed services it provides considerably, including databases and now various classes of machine- and deep-learning algorithms exposed as a service. In most of those cases, it is replacing a task that previously was performed by IT operations staff with an automated service. That may appeal to IT organizations that have standardized completely on AWS. But in a multi-cloud world where elements of applications are deployed both on-premises and across multiple public cloud services, it remains to be seen the degree to which organizations will want to employ managed services that only automate AWS processes.

    One thing’s for certain: DevOps processes across multiple computing environments are becoming more automated. As microservices architectures become more widely employed, many organizations in the months and years ahead will become a lot more comfortable mixing and matching various cloud services as they see fit. Within that context, automation of DevOps processes will need to be multiplatform almost by definition. As a set of services exposed via application programming interfaces (APIs), it may very well turn out that the automated managed services provided by AWS can be programmatically invoked by other DevOps management frameworks.

    Of course, there are plenty of organizations that, for now at least, have standardized on AWS. DevOps delivered as a managed service by AWS clearly has some appeal for those organizations. But as cloud computing continues to mature, the number of organizations employing only one cloud service is expected to decline.

    While the battle of control of the cloud has been mainly focused on developers, more attention now is being paid to how application development pipelines get managed in the age of the cloud. Each IT organization will have a unique set of processes and requirements for managing those pipelines. In fact, the issue going forward will be to what degree can cloud service providers (CSP) adapt to those processes versus making the IT organization adapt to the CSP.

    In the meantime, IT organizations would be well-advised to establish the roles and functions they need to manage those automated pipelines sooner than later.

    — Mike Vizard

  • Australian DevOps Company to Open US Office in 2017

    Australian DevOps Company to Open US Office in 2017

    Australia-based DevOps as a managed service provider base2Services is preparing to establish a U.S. office in mid-2017.

    Despite being based in Melbourne, Australia, base2Services already has five customers in North America—including media company All Day and online video specialist Sardius Media—that contribute nearly 20 percent of the company’s revenue. Further expansion in the region will require staff in a similar time zone to potential customers, said managing director Arthur Marinis.

    “Our service is unique in the fact that everything we do and say is aimed at helping development teams at existing companies, big or small, leverage the cloud and automate. They are the ones with the knowledge of how vital it is to speed up development times and to have the ability to change quickly. Those are the ones searching for DevOps around the world.”

    He added, “They have found we are able to provide the right consulting and managed services to help them migrate to the cloud, optimize their cloud infrastructure and implement DevOps processes. They aren’t nervous about our location as they use the cloud, and most are used to working remotely, it helps that we also provide 24/7 support.”

    base2Services’ policy of charging a fixed monthly price to development teams to help them build and manage scalable and agile cloud-based solutions presumably helps.

    So far, only one potential customer was put off by the idea of working with an Australian company, Marinis said. But, “Our cultures aren’t all that different,” and culture is particularly important for DevOps.

    The company often is asked to prove its expertise, in which case its preference is to organize a meeting between its technical staff and their counterparts at the prospective customer. “That solves the issue in most cases,” he said.

    Location, Location, Location

    Although most of its customers are in California, base2Services currently plans to locate the new office in either Boulder, Colorado; Kansas City, Kansas; or Austin, Texas. Marinis described Kansas City as a high-growth area for DevOps, and said inland areas of the United States offer a good supply of talent at more affordable prices than California. Another benefit of these cities is that their time zones provides a better crossover with eastern Australia.

    Indeed, the time difference between the United States and Australia has proved beneficial to North American customers, Marinis said. Australian-based staff can talk to their client’s developers and then work overnight (according to an American clock) and have the results ready when the developers arrive at work the next morning. “It actually helps them move faster.”

    It also makes it easy for base2Services to provide out-of-hours support.

    All the U.S. staff will be hired locally, with the first appointment expected before Christmas. An experienced member of the Australian team will work in the U.S. office for six months to teach the recruits “the base2 way,” Marinis explained.

    He said the company was still focused on Australia and wanted to grow its customer base by 200 percent over the next 12 to 18 months. It focuses on startups and SaaS providers, and there are many more of those in the United States, he observed. In time, base2Service’s U.S. business could be five times the size of its home operation, Marinis predicted, though he added, “We’re very confident that we will remain Australia-based. This is where our hearts are.”

    — Stephen Withers