TAKE NOTE (Insights and Emerging Technology)
The CIO-SP3 government wide acquisition contract for IT services operated by the National Institutes of Health were again extended, this time for nine months, while bid protests over the embattled successor CIO-SP4 persist.
In an update posted this week, NIH’s Information Technology Acquisition and Assessment Center (NITAAC) said that CIO-SP3 and its small business counterpart would be extended through April 2025 to ensure there won’t be a break in service.
The extension “ensures CIO-SP3 and CIO-SP3 Small Business are available for use during the busy end of year buying season. From laptops to desktops to everything IT, NITAAC will continue to be your one-stop shop for all your IT acquisition needs,” the post said.
The new extension of CIO-SP3 — which stands for Chief Information Officer-Solutions and Partners 3 — comes as its fourth iteration continues to face challenges from companies competing for awards. That contract, CIO-SP4, is a 10-year contracting vehicle valued at $50 billion. NITAAC began soliciting proposals for CIO-SP4 in May 2021.
After the resolution of dozens of bid protests last summer and the agency’s commitment to corrective action, NITAAC in January began sending new notices to successful and unsuccessful offerors. Almost immediately, bid protests at the Government Accountability Office and the U.S. Court of Federal Claims resurfaced, and in February, NITAAC announced it was requesting to extend the contract through October.
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
Decoding SAP HANA Deployment Options
Intro
As businesses look to modernize their operations and leverage advanced technologies, choosing the right deployment option for SAP HANA becomes a crucial decision. With SAP HANA offering both on-premise and cloud options, businesses need to understand the key differences and benefits of each to make an informed choice. This blog will delve into the specifics of “SAP HANA On-Premise vs Cloud,” helping you determine which option is best suited for your business needs.
Understanding SAP HANA
SAP HANA is an in-memory, column-oriented, relational database management system developed by SAP SE. It serves as the foundation for SAP’s next-generation business suite, SAP S/4HANA, which helps businesses perform transactions and analytics in real-time. As businesses transition from older ERP systems to SAP S/4HANA, they must decide whether to deploy SAP HANA on-premise or in the cloud.
If you want a nuts and bolts understanding of SAP HANA, Id take a look at this blog The ABAP Developer Road Map to SAP HANA
If you want to understand SAP Suite on HANA, or S/4 Hana the next generation business suite running on SAP HANA, the the blogs below will help:
What is SAP Suite on Hana (SoH)?
What is S/4 Hana and How Is It Different Than Suite on Hana
SAP HANA on-Premise
Deploying SAP HANA on-premise means the hardware and software are physically located within the company’s own data centers. This deployment option provides full control over the IT environment, allowing businesses to customize and manage their systems according to their specific requirements. By keeping the infrastructure on-site, organizations can implement security measures tailored to their needs, ensuring data integrity and compliance with industry regulations. This setup also facilitates seamless integration with other on-premise systems and legacy applications, enhancing overall operational efficiency.
Key Features of SAP HANA On-Premise:
- Full control over data and systems: Deploying SAP HANA on-premise allows your business to maintain complete control over data storage and management. This ensures that sensitive information remains secure and complies with industry-specific regulations and internal policies.
- Customization and integration flexibility: On-premise deployment offers extensive customization options, enabling businesses to tailor the system to their unique requirements. This includes integrating with existing on-premise applications and customizing functionalities to fit specific business processes seamlessly.
- No reliance on internet connectivity for operations: By keeping your SAP HANA system on-premise, your operations are not dependent on internet connectivity. This guarantees continuous access to critical business applications, even during internet outages or connectivity issues.
- Higher initial capital expenditure for hardware and infrastructure: Setting up an on-premise SAP HANA system requires a significant upfront investment in purchasing and installing hardware and infrastructure. This initial cost can be substantial but is balanced by potential long-term savings and control over resources.
- Responsibility for maintenance, updates, and security: With an on-premise deployment, your IT team is responsible for all system maintenance, including applying updates and patches, managing security protocols, and ensuring the system runs smoothly. This requires dedicated resources and ongoing attention.
– Dig Deeper –
SAP On Premise VS Private Cloud Vs Public Cloud
Q&A (Post your questions and get the answers you need)
Q. What is Infrastructure as Code?
A. Infrastructure as code (IaC) is the process of provisioning and managing resources in public clouds such as AWS, GCP, and Azure via a set of editable text files that describe how and where infrastructure resource configurations are deployed.
These input scripts are ingested by Infrastructure as Code tools which then automatically create, update, or delete resources to ensure that the cloud infrastructure complies with the state defined in the IaC file. IaC tools are designed to manage the implicit and explicit dependencies between cloud infrastructure resources so that the creation, maintenance, and removal of resources is performed logically and takes into account these resource dependencies.
Before Infrastructure as Code (IaC) existed, resources were typically provisioned manually or, at best, through simple scripts like shell scripts or Python. Configuration management tools were very efficient when it came to configuring an instance once it was up and running, but had a gap in the ability to create the instance in the first place.
IaC emerged to help bridge this gap by automating resource provisioning and thus move away from snowflake servers. What the hell is a snowflake server? Well, it can be finicky business to keep a production server running. You have to ensure the operating system and any other dependent software is properly patched to keep it up to date. Hosted applications need to be upgraded regularly. Configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. This requires some mix of command-line invocations, jumping between GUI screens, and editing text files.
The result is a unique snowflake – good for a ski resort, bad for a data center.
The introduction of high-level declarative languages to define a desired state, along with the IaC tools that automatically implemented those declarations, was a big leap forward within the industry.
Infrastructure as code (IaC) brought many benefits, among them:
- Speed and standardization: Allowing your desired state to be written in scripts for perfect reproducibility.
- Version control: Enabling these scripts to be saved in Git, thus allowing you to maintain a history of your infrastructure, as with application code.
- Documentation: Allowing the scripts to serve as documentation and a single source of truth.
- Efficiency: Extending the possibility of continuous deployments to the provisioning and management of the resources themselves.
The three major public cloud providers all offer their own custom IaC solutions, which work only for their own respective platforms:
- Amazon Web Services offers AWS CloudFormation.
- Microsoft Azure’s platform is the Azure Resource Manager.
- Google Cloud Platform uses Google Cloud Deployment Manager.
Terraform is the most widely used cloud-independent IaC software and offers the advantage of supporting many cloud vendors.
The automated configuration management software vendors, including Puppet, Chef, and Ansible, have also been working to expand their capabilities and today, offer some level of support for creating, updating, and deleting resources in public clouds. However, they were not designed as IaC from the ground up.
Hope this helps!
Cheers!